ASP.NET & .NET Framework served us well for a pretty long time and developers could build sophisticated and high performance applications. The framework took some time to mature like any other framework but was pretty well accepted over time. One big disadvantage the framework had was dependency on the Windows ecosystem. For many SMB’s, the additional cost involved would not make a lot of sense which led to the popularity of open source technologies. Microsoft then made some critical announcements such as the decision to Open source .NET, discontinuation of the .NET framework. Open source has made it easier for .NET to be cross platform which makes it cost effective.

.NET Core version?

Microsoft came up with a lot of releases initially with versions 1.0, 1.1, 2.0, 2.1, 2.2, 3.0, 3.1 and 5.0. According to the .NET Core support policy, all versions before .NET Core 3.1 are no longer supported and 3.1 is at LTS (Long Term Support). The next LTS version (6.0) is slated to be released in November 2021. 

Note: Developers looking to build production applications should opt for LTS releases

Code Editor

With .NET Core being cross platform, developers now have a choice of tools in front of them which can run on Windows, Linux or macOS. Developers can opt for the licensed Visual Studio or free lightweight editor Visual Studio Code which runs on all major platforms. Visual Studio Code has become a popular choice among developers due to the wide variety of extensions.

Now let’s head to some of the differences between .NET Core and the decommissioned ASP.NET framework.

Dependency Injection (DI)

This is a great feature which is built-in in ASP.NET Core. This feature facilitates loose coupling of components and services which is ideal for building highly scalable applications.

Data Protection

ASP.NET Core has built-in support for Data protection through the IDataProtector interface which can be used to encrypt and decrypt data sensitive data. 

Middleware

All classes that implement IHttpHandler and IHttpModule are affected by this change as they have been discontinued in ASP.NET Core. The order of middleware is based on the order in which they have been inserted into the request pipeline. ASP.NET Core ships with a lot of built in middleware which can be enabled on demand by developers based on their requirement and can also add infinite custom middlewares to the request pipeline.

NuGet Packages

NuGet packages used should support .NET Core or .NET Standard. Most third party libraries support them. If they aren’t supported then you need to lookout for replacements. 

.NET Standard indicates that the package can be used both in .NET Framework 4.6.1+ and .NET Core.

Older .NET Framework packages can be used by .NET Core applications provided they run on Windows machines which is not recommended as you tend to lose cross platform functionality.

Application Configurations

In ASP.NET, developers used the web.config file to store all application configuration which has been discontinued in ASP.NET Core. appSettings.json is the new replacement which works on similar lines. Applications can read these settings using the ConfigurationManager.AppSettings collection OR through the IConfiguration interface which can be injected through DI.

Global.asax file

This file was the entry point for ASP.NET applications which has gone away. With ASP.NET Core Startup.cs is now the entry point for an application.

Static files

In ASP.NET static files such as HTML, CSS, Javascript and images were stored in various directories where as in ASP.NET Core, static files are stored in the web root (<content root>/wwwroot) which is the default location and is configurable. The files are loaded into the request pipeline only if the extension method UseStaticFiles() has been invoked from Startup.Configure.

Web Forms (ASPX)

ASP.NET Web Forms isn’t supported in .NET Core. All existing Web Forms need to be migrated to Razor pages. If there is an option to completely rewrite the code in these pages, Blazor can be considered. Blazor is a feature of ASP.NET Core that let’s you build interactive web UIs using C# instead of JavaScript.

WCF

Server side WCF isn’t supported in .NET Core. Developers are suggested to use different communication technologies such as gRPC or REST. 

Session

Session is not enabled by default in ASP.NET Core and must be manually enabled using extension methods.

To enable Session Middleware the application must contain the following:

• Any of the IDistributedCache memory caches
• A call to AddSession in ConfigureServices 
• A call to UseSession in Configure

The following code shows how to set up Session in ASP.NET Core.

public class Startup {     public void ConfigureServices(IServiceCollection services)     {         services.AddDistributedMemoryCache();         services.AddSession(options =>         {             // Set a short timeout for easy testing.             options.IdleTimeout = TimeSpan.FromSeconds(10);             options.Cookie.HttpOnly = true;             // Make the session cookie essential             options.Cookie.IsEssential = true;         });     }     public void Configure(IApplicationBuilder app, IHostingEnvironment env)     {         app.UseSession();            } }

ASP.NET & ASP.NET Core Sessions are not compatible with each other as they follow completely different DB Schema.

Note: Microsoft recommends against the use of Sessions and to make an application stateless. But in some use cases, an application needs to be stateful.

Summary

Migration to .NET Core does have a lot of effort which needs to be planned well. But considering the advantages it offers such as Cross platform compatibility, built-in support of many features such as DI, Data Protection which facilitates better design patterns, an active community which addresses most concerns on GitHub, the ability to scale up applications with the help of container-orchestration technologies such as Kubernetes it is definitely worth it for organizations looking to build stable applications and also helps them cut down on costs.