ASP.NET Core 2.0 Preview 1 is already out and you can start building application with ASP.NET Core 2.0. At the time of writing this post, it is still in Preview 1 and final version is expected to be released in Q3-2017. To build ASP.NET Core 2.0 based application, you need to install Visual Studio 2017 Preview 3. Since this is a major release, expect some code breaking changes and a few new pieces. In this post, I try to put together a quick and short summary of what’s new in ASP.NET Core 2.0 compared to ASP.NET Core 1.1.
Here is what’s new in ASP.NET Core 2.0
If you are new to ASP.NET Core, please read first, Quick summary of what’s changed in ASP.NET Core and you can also check out my other post for ASP.NET Core 1.0. Let’s see what’s new in ASP.NET Core 2.0.
- ASP.NET Core 2.0 implements .NET Standard 2.0. This allows you to use missing .NET Framework pieces with ASP.NET Core like Datasets, Binary Serialization, Reflection and many other pieces. Read What’s new in .NET Standard 2.0
- ASP.NET Core application can be created via dotnet cli also. The following command creates a new ASP.NET Core web application.
dotnet new web
Once this command is completed, you need to execute another command to restore all the packages.
You don’t have to execute this extra command with .NET Core 2.0. Restoring packages is now part of the
- ASP.NET Core 2.0 application now references a single meta package
Microsoft.AspNetCore.Allto include all ASP.NET Core packages with the product version. This makes .csproj file short and clean. Here is a sample ASP.NET Core 2.0 sample .csproj file (Line no. 13).
It is a super easy way to include all the ASP.NET Core packages reference without worrying about their different version. You no longer have to pick individual ASP.NET Core packages. But wait, when ASP.NET Core was introduced, there was so much hype about being modular and bring only what is needed. For example, If you want MVC then include its package. Many developers liked this as it brings down the size of the application. So are we moving from being modular?
The answer is NO. If you don’t like this package of packages thing, you can still follow the traditional way of including needed packages. Then, why this one big package is introduced? Well, maintaining, updating and removing unwanted packages requires some efforts and it’s kind-of painful. The other problem would be to remember the package name.
By now, you must be cursing Microsoft and concerned as this would add unnecessary crap to your application, restoring will take ages and make your application heavy. You have already started thinking about the performance of the application :). Your concern is right, but stop cursing Microsoft because, the .NET Core SDK already has all the packages included inside of
Microsoft.AspNetCore.All, so you are never downloading them from the web. It is all available on your machine. Phew!!!
What about Deployment? Well, if there are features you don’t need in your application, the new package trimming features will exclude those binaries in your published application output by default.
- ASP.NET Core 2.0 introduces a new way to build web host configuration. This new approach sets the defaults of the web host configuration using
Familiar Program.cs (ASP.NET Core 1.1)
In ASP.NET Core 2.0, it looks like this:
BuildWebHostis an expression bodied function member introduced in C# 6. This method calls a static method
CreateDefaultBuilderwhich adds Kestrel, IIS configuration, default configuration sources, logging providers, and the content root. Instead of you doing all this, the
CreateDefaultBuilderwill do it for you. You can take a look at the code of this function here.
- Logging and building configuration is no longer part of
Startup.csfile. It is now part of
CreateDefaultBuilder, called in
Startup.csin ASP.NET Core 1.1 project looks like this:
In ASP.NET Core 2.0, it looks like this:
As you can see, the constructor no longer takes
IHostingEnvironment, instead takes the
IConfigurationinjected dependency and sets the Configuration property for later access if needed. Another change is in the
Configuremethod as logging is no longer part of this method.
- ASP.NET Core 2.0 introduces Razor Pages. Razor Pages are simple pages or views without controllers associated to it. Razor pages are included with
Microsoft.AspNetCore.Mvcpackage. They work on the convention and needs to be placed in Pages folder and the extension is .cshtml. Following is a sample razor code page.
They must use
@pagedirective on top as the first directive. You can write razor page with inline model (using
@functionsdirective), separate page models (called Pages Models) and with no models. Routing works quite well with Razor pages. Please visit the official documentation for more details.
- The Platform Abstraction API responsible for application environment information is removed. Please visit this link to find out the replacement.
- Authentication has undergone some major changes for 2.0. All Auth middleware are services now and there is now only a single authentication middleware is needed which is
app.UseAuthentication(). In .NET Core 1.1, to enable cookie authentication,
The options w.r.t. to cookie authentication is specified in
Configure()method. This is changed in 2.0. Now, it is done like this:
As you can see,
Configure()method now just adds the authentication middleware to pipeline without specifying any configurable options for authentication mechanism. The following table shows name changes of some of the authentication middleware.
|ASP.NET Core 1.1||ASP.NET Core 2.0|
For more details, take a look at this github link.
You can also check out this github announcement link for other changes. That’s it.
Since ASP.NET Core 2.0 is a major release, you would expect some new features and code breaking changes. At the time of writing this post, it is Preview 1 release and things may change when the stable version comes out. This post takes you through a quick summary of what’s new in ASP.NET Core 2.0 based on the Preview 1 release. It is very unlikely that these things will change/update drastically, but you never know with Microsoft. As the history of ASP.NET vNext suggests otherwise.
Thank you for reading. Keep visiting this blog and share this in your network. Please put your thoughts and feedback in the comments section.