ASP.NET Core Schedule and Roadmap
Below is the schedule and roadmap for ASP.NET Core. Please note that these dates and feature plans are all subject to change. As with any project of this size it is difficult to predict exactly when things will land. Even so, we think it's important to be as open and transparent as possible about our plans so that our users can have the right expectations and create their plans accordingly.
Schedule
| Release | Time frame* |
|---|---|
| 2.0-preview1 | Q2 2017 |
| 2.0-preview2 | Q2 2017 |
| 2.0 | Q3 2017 |
| 2.1 | Q1-Q2 2018 |
* References to yearly quarters (Q1, Q2, Q3, Q4) are calendar-based
2.0.0 Roadmap
These are the major features and work planned for the 2.0.0 release.
Alignment with and support for .NET Standard 2.0
ASP.NET Core 2.0 will support loading libraries targeting .NET Standard 2.0, when running on .NET Core 2.0 and .NET Framework 4.6.1. The ASP.NET Core 2.0 packages themselves will target .NET Standard 2.0 such that why can be referenced by other .NET Standard 2.0 libraries, and run on .NET Standard 2.0 compliant platforms.
Simplified package referencing & with new meta-package Microsoft.AspNetCore.All
When running on .NET Core 2.0, ASP.NET Core 2.0 applications will be able to use the new ASP.NET Core meta-pacakge Microsoft.AspNetCore.All. This package will bring in all of the packages made and supported by the ASP.NET Core and Entity Framework Core teams, along with their internal and 3rd-party dependencies, such that all features are present by default. The version number of this package will always represent the latest ASP.NET Core version (aligned with the .NET Core version) such that only a single runtime version number need be reasoned about.
Customers are still able to reference individual packages instead of the meta-package if they wish.
Smaller published application sizes and faster startup times by way of the .NET Core 2.0 Runtime Store & automatic Razor view pre-compilation during publish
Applications using the new Microsoft.AspNetCore.All will automatically take advantage of the new .NET Core Runtime Store, which will contain all the runtime assets needed to run ASP.NET Core 2.0 applications by default, removing the requirement to have assets from the referenced ASP.NET Core NuGet packages deployed with the application. These assets are also pre-JIT'ted such that application startup-time is improved.
Also, Razor view pre-compilation will enabled during publish by default, further reducing the publish output size and application startup time.
Hosting startup
ASP.NET Core & .NET Core 2.0 will introduce new features to enable hosting environments to inject extra package dependencies and execute code during application startup, without the application needing to explicitly take a dependency or call any methods. This feature can be used to enable certain environments, e.g. debugging in Visual Studio, hosting in Azure App Service, etc., to "light-up" features unique to that environment without the application needing to know ahead of time.
Application Insights features will be automatically enabled in ASP.NET Core 2.0 applications when debugging in Visual Studio and (after opting in) in Azure App Services using this mechanism. As a result, the project templates will no longer add Application Insights packages and code by default.
Correlated tracing support
Support for correlated service tracing will be added to the hosting layer, such that incoming requests containing meta-data about related services will result in request tracking identifiers being correlated in supported systems, e.g. Application Insights. This will allow ASP.NET Core applications spanning many service instances to track requests as they flow through these instances.
Configuration & Web Host defaults
An IConfiguration instance will be added to the services container by default in ASP.NET Core 2.0, so that all applications can easily retrieve configuration values via the container. In addition, a new WebHost API will be added that makes it easy to create an IWebHostBuilder instance with opinionated defaults including use of Kestrel for the web server, logging providers, and configuration sources, removing the need for this common boilerplate configuration to be in every project. Furthermore, more parts of ASP.NET Core 2.0 will support being configured automatically via the new default IConfiguration, including (where appropriate) support for reacting to configuration changes while the application is running, e.g. Kestrel endpoints, logging providers, etc.
Identity Application Services
A service layer will be added ASP.NET Core Identity and included in the project templates using Individual Authentication. This will allow authentication of users by way of JWT tokens such that Web APIs can be secured out of the box, and make it simpler to change authentication systems, e.g. from in-app Identity to Azure AD B2C, or 3rd-party solutions like Identity Server.
Support for Azure AD B2C authentication
New project templates including integration with Azure AD B2C authentication will be provided.
Health checks
A new set of primitives will be added that enable an application to report its health status. This could include custom checks to ensure dependent systems are available (e.g. file system, database, etc.). This status can be used as part of a larger orchestration system to ensure application instances are suitable routed to or re-provisioned in the case that they are unhealthy.
Kestrel edge readiness
Features are being added to Kestrel to make it more suitable as an Internet-facing server, including various configurable timeouts and limits.
Razor Pages
Adding of a page-focused programming model to MVC, built on the existing primitives but optimized for typical scenarios and patterns seen in server-side HTML rendering.
Security
Updates to the design of ASP.NET Core Security middleware and services based on feedback from 1.x, to make it easier to use and more deliberate about supported scenarios.
2.1.0 Roadmap
SignalR
New SignalR for ASP.NET Core