What to Expect When Transitioning to ASP.NET MVC Core

July 20th, 2016

With the latest release of ASP.NET Core, developers are wondering what the next step is for their web apps and how to convert it over to the new ASP.NET Core.

Before the release of ASP.NET Core, a couple of posts made me sit up and take notice regarding what was to come in the new version of ASP.NET Core.

One post was Discontinued Technology in .NET Core and the other one was Porting to .NET Core from Microsoft.

I know I shouldn't say this, but I assume these posts were spawned from this GitHub post?

Some of the technologies left behind include:

Each one is described in detail why they aren't available in ASP.NET Core.

Four days ago, the .NET Core Roadmap was released to show what's in store for .NET Core. Since the release of .NET Core 1.0, now the team is focusing on implementing the other technologies and enhancements into .NET Core (i.e. SignalR).

For those who have web applications who want to upgrade their web application to ASP.NET Core, they may have to wait until the end of the year or even the beginning of next year for these technologies to appear in .NET Core (they mentioned Q4 2016/Q1 2017 in the roadmap).

However, for those wanting to update their ASP.NET MVC or WebForm applications to ASP.NET Core, how different is it from what everyone is used to and how easy will your applications transition to ASP.NET Core?

Converting To ASP.NET Core

I know I posted the 5 Factors To Consider When Converting a WebForms App to ASP.NET MVC Core, but I wanted to share some other observations.

For those new ASP.NET MVC web developers who are using version 4 or 5 and then they dive into ASP.NET MVC Core, they will notice the following changes.

No Bundling/Minification

In a pre-Core MVC application, you had an App_start folder that held all of your startup configurations like RouteConfig.cs, WebApiConfig.cs, and BundleConfig.cs.

Now, your bundling and minification occur using task runners like Grunt or Gulp for the client-side or front-end tooling.

Instead of writing code to bundle or minify your CSS and/or JavaScript, developers need to write JSON tasks to accomplish the same thing. 

These command-line tools are now integrated into Visual Studio providing quick assistance to making your client-side tasks even easier.

No ConfigurationManager

In a recent post, I mentioned how this new configuration works in your web application.

It's a different way of thinking, but provides a better way of storing configuration settings.

It's recommended to have all of your configuration settings located in one area of your application so you don't have ConfigurationManager.AppSettings strewn all over your web app. Centralize your configuration.

Middleware: The New Pipeline

The biggest change to happen to ASP.NET web development is the introduction to Middleware. This requires the developer to think through how all pieces of technology function within the web application.

Each section of the pipeline describes the technology used (app.UseMvc(), app.UseSqlServer(), app.UseEntityFramework(), etc.) as well as the configuration for each.

I would consider this as the entry point for your ASP.NET Core web applications.

Convert your App_Start configs into the following:

For more info regarding Middleware, I could not cover this topic any more thoroughly than Jerrie Pelser (@jerriepelser) did with his video on Middleware on ProCoder.

Dependency Injection

ASP.NET MVC Core provides dependency injection right out of the box. It's used throughout Core as constructor injection as well as property injection (as I found out with my A/B TagHelper).

Since this is isn't too much of a shock for those using Dependency Injection in ASP.NET MVC with their own DI library like Ninject, StructureMap, or Unity, ASP.NET Core already provides the hooks to include your own favorite DI library if you want.

With that said, you have the option to use Microsoft's DI implementation.

System.Web Went On a Diet

The System.Web assembly was a whopping 30 megs of web code before ASP.NET Core appeared. Once that was simplified and scaled down, it was easy to start implementing more granular web technologies.

A side-effect of a smaller System.Web was the quicker initialization of websites when deployed.

I know this is easier said than done, but to convert over to a ASP.NET Core application, I would suggest limiting your dependency on HttpContext and only use it where it makes sense.

Conclusion

If you've been coding for a while in ASP.NET MVC, there really isn't too much that changed regarding Core.

Yes, I know it was a complete rewrite from the ground up, but think about all of the MVC code you wrote in the past.

If you have a simple MVC code base, the only thing you need to worry about is setting up the middleware and letting your IDE assist you with your bundles, minification, and image optimization.

Since ASP.NET MVC has been the "core" of the onion over the years, has stabilized, and is considered the future of the .NET technologies, with the release of ASP.NET Core, it was time for the environment to change around ASP.NET MVC as well.

From my perspective, when ASP.NET Core was introduced, the ASP.NET MVC code and concept is still the same.

It was the environment around it that changed.

Did this make sense? What was the major change that you noticed in ASP.NET Core 1.0? Post your comments below.