The 15.3 preview of Visual Studio 2017 includes the ASP.NET Core 2.0 preview; this now includes the SignalR library for building real-time web functionality with Web Sockets (and older techniques for older browsers) and the new Razor Pages app model. This is a lightweight syntax for combining C# server code with HTML for building web applications that don’t need the power or complexity of full MVC. Instead of having a model, and a view and a controller all in separate folders, Razor pages puts all three onto the same page. It’s still the MVC model, so tag handlers and model bindings and dependency injections all work and you can use Razor pages in existing MVC apps for the simpler parts of the UI. If you need to add more functionality to a page later on, you can turn it into a view and move the code into a controller and make it a full MVC.
While it’s possible that there will be VB templates for ASP.NET Core 2, don’t expect a VB version of Razor; that will stay as HTML and C#.
There are also a lot of improvements that .NET and ASP.NET program manager Scott Hanselman refers to as “removing paper cuts” from the developer experience; from templates that set up things you used to have to do manually when you create a new project the templates, to 25% faster throughout and faster startup because views are precompiled, but all in a runtime that’s only 3MB. That’s because ASP.NET Core and Entity Framework Core are now included in .NET Core, so your ASP.NET Core app doesn’t need to publish the whole of ASP.NET every time you deploy it. .NET Core 2 and ASP.NET Core 2 no longer reference all the individual packages that make up .NET (that proved to be complex and fragile), just a superset that’s the package of packages; only the packages you need are deployed and if you prefer you can de-reference that superset and pick the individual packages you want.
If you don’t want to run your own identity system for a web app, you can now use any Open ID Connect identity provider with ASP.NET Core 2, including Azure AD B2C; that’s an Azure service that can manage accounts and sign ins for a web site using the same secure identity management as Azure AD, but for any consumer email address.
You can now set up continuous deployment pipelines for ASP.NET and ASP.NET Core projects on Azure Web Apps directly from Visual Studio, with the Continuous Delivery Tools extension; that will soon support Node.js, PHP and Python apps (as a preview). The preview release of Visual Studio 2017 also now lets you containerise ASP.NET apps, just by right-clicking on them and adding Docker support; that generates the Docker Compose file for an existing project, not just a new project. That automatically switches .NET applications that need IIS and ASP.NET to deploying into a Docker container, making it easier to extend existing applications with new microservices.
Containerising ASP.NET applications also gives you new options for hosting them on Azure Service Fabric. Alaska Airlines moved the Alaska.com site from IIS to a Service Fabric cluster, hosting it in Docker containers so they can scale up and down. Integrating that with Visual Studio for debugging has been complicated, because it’s meant going through Service Fabric reverse proxies as a gateway to forward requests to new services. Service Fabric plans to support isolated networks for communicating between multiple containers deployed as an app and fixed IP addresses for each application, which will simplify this.
The new Service Fabric API Management (due to launch this summer) will also help, by supporting service discovery, routing and partition resolution, so you can make calls directly to your back-end services and even to a specific service instance. “The way this works is when a request comes in to API Management, API Management is now aware of Service Fabric’s naming service and so it does the resolution, it does the lookup and then it can intelligently route that call to the right place,” program manage Mark Fussell explained at Build. That uses a new HTTP client library that will be available as NuGet packages, so you’ll be able to do Service Fabric management without installing the entire Service Fabric runtime and SDK on your machine.
The advantage of that is that they start more quickly on the Functions service than functions written as scripts. Functions run when the trigger you create is detected (triggers can be anything from a new entry in a database or a record in Salesforce getting updated or an HTTP request), and they use bindings to connect to the data your code operates on (which can be on Azure or an external service), but all the code of your function has to be loaded before it runs.