Migrate to .NET Core from an ASP.NET 4.5 MVC web app [closed]

Question

I've just been given an assignment with some tech I'm not that familiar with - our lovely windows ASP.NET MVC web app should be converted to be used in a linux environment.

I work in health and we have user data that absolutely cannot be lost or heads will roll (ours or theirs).

I'm typically not a C#/ASP.NET guy - though I can adapt for the task. I've been reading over the official docs @ http://docs.asp.net/en/latest/getting-started/installing-on-linux.html and can see that this task in effect means 'target the .NET CORE (or mono) framework'.

I've googled around and there is no de facto / easy way of migrating it seems - just learn the new modular setup with the configs slapped into project.json and away you go! Before I try and do this manually - is there any info you guys could advise me on? Some systematic processes to follow? Perhaps some "gotchas" that I ought to have read beforehand?

The project uses NHibernate and Autofac for DI - seems pretty standard. I just wanted to know how much reading/experimenting this would take to get it running on a linux server - ultimately that's what counts.

Answer 1

The answer below is outdated but outlines a working solution for updating a .Net 4.5 MVC application to the .Net Core framework. .Net Core is ready for production

The Core CLR, and BCL are not ready for production. Period. At least not yet and probably not for six months to a year. Dependency support is even more of an unknown at this point. Autofac has no core clr compatible library. Will they? That is somewhere to start researching. When will they? It could be a while and that is a project requirement that is outside your control.

Even for non production work .NET core is still very early. The simple answer would be to tell your boss to wait six months and see how everything shakes out rather than potentially burn hundreds of man hours or pre-production code. Of course that is likely to be ignored so here is how I would proceed today if I absolutely had to.

There are a couple of changes rolled together in your question. You are looking to migrate from ASP.NET 4.5 to ASP.NET 5. You are also looking to target a new framework. Lastly you are planning on running the solution in a new environment. Each of these can be handled independently (although some not before others) so that is the route I would take.

Phase 0) There are no DNX supported versions of the .Net framework prior to 4.5.1. You will be using DNVM to select a DNX to target. You can't target what isn't available so if your project is currently targeting something prior to 4.5.1 update that and verify there are no breaking changes. If there are fix and keep condebase compatible with 4.5.1 or later.

---

Phase 1) DNVM and DNX are compatible with both the existing "full" .Net Framework (4.5.1+) and .Net Core (5.0). It may be tempting to jump right to ASP.NET 5 running on .Net Core 5 but that would be a mistake. Since .Net Core requires a dnx based project and dnx based projects also support .Net 4.5.1 (or later), the first step would be to switch to the new project structure introduced by asp.net 5. It will probably require some experimentation and documentation is spartan at this point. The target would be your existing application (asp.net 4.5 running on .net framework 4.5.1 running in the dnx. There are no project migration wizards so you will be starting from a new dnx project (use asp.net 5 "empty" template) and copying in your existing code. This may seem a minor change but it breaks that tight coupling of the application to an installed framework on the windows only host. Once you have the codebase running in a dnx environment you have the groundwork laid to target other environments.

Phase 2) Migrate to asp.net 5 (MVC 6). You will still be targeting the "full" .net framework and running on windows. .Net core does not (and never will) support your project's existing asp.net version (4.5). However asp.net 5 is compatible with both the full framework (4.x) and core (5). This gives you the ability to upgrade to asp.net 5 without changing over to .net core. The target at the end of phase 2 is the web application (functional) using asp.net 5 running on .net 4.x in dnx. Yes still on windows but we are getting closer to cross platform compatibility.

Phase 3) Take inventory list of existing BCL references and dependencies which are not supported in .net core. Refactor existing BCL references which are not supported in .net core. Remember .net core is a subset of the full framework so you might get lucky and all existing code meets that subset but if you don't you need to find a way to achieve the same functionality with the subset available in .net core.

For dependencies (i.e. Autofac) it is very likely you are going to need to upgrade and there may be breaking changes which need to be resolved. The target and the end of phase 3 is the web application from phase 2 but without any dependencies that are incompatible with the core bcl. The largest factor outside your control is third party packages. If autofac doesn't release a core clr compatible package then you are stuck (or will need to consider using an alternative).

Phase 4) The end of phase 3 means you have a .net core compliant stack but you are still targeting the full framework. Now finally you will switch the target to core clr (dnvm supports multiple side by side runtimes = dnx). I would still deploy to windows at this point, one variable at a time. At the end of Phase 4 you have the web application running on .net core hosted in windows environment.

Phase 5). Now you can work on resolving any Windows dependencies. At a minimum look to migrate off IIS, ensure any path handling is done in an OS neutral way, and there are no calls to windows specific resources (like registry). The core clr and bcl should be more mature by this point so you aren't trying to aim for a moving target.

Trying to do it all in one go is in my opinion a recipe for disaster. With so many parallel changes you will start with a non-functional solution and it will probably remain non-functional. By taking it in phases you can migration the solution towards a cross compatible target while still having functional output at each step of the way.

Answer 2

I know this is old question, but need to update I guess. Because some of production application migrating asp.net mvc to asp.net core. I gather up some step by step migration. I'll hope its gonna be useful.

Yes it is possible.

1) Create a new empty ASP.NET Core web app with the same name as the previous project. So namespace will be match.

2) Install the Microsoft.AspNetCore.Mvc and Microsoft.AspNetCore.StaticFiles NuGet packages. The ASP.NET runtime is modular, and you must explicitly opt in to serve static files

3) Open the .csproj file and add a PrepareForPublish target: For example

  <Exec Command="bower install" /> </Target> 

4) Open the Startup.cs file and change the code to match the following:

namespace WebApp1 {     public class Startup     {         public void ConfigureServices(IServiceCollection services)         {             services.AddMvc();         }          public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)         {             loggerFactory.AddConsole();              if (env.IsDevelopment())             {                 app.UseDeveloperExceptionPage();             }              app.UseStaticFiles();              app.UseMvc(routes =>             {                 routes.MapRoute(                     name: "default",                     template: "{controller=Home}/{action=Index}/{id?}");             });         }     } } 

5) Add a Controllers folder.Then add MVC controller class with the name HomeController.cs to the Controllers folder.

• Add a Views folder.
• Add a Views/Home folder.
• Add an Index.cshtml, MVC view page to the Views/Home folder.

For mid test please do following

Replace the contents of the Views/Home/Index.cshtml file with the following:

<h1>Hello world!</h1> 

---

6) Migrating functionality from the ASP.NET MVC project. We will need to move the following:

• client-side content (CSS, fonts, and scripts)
• controllers
• views
• models
• bundling
• filters
• Log in/out, identity

7) Copy each of the methods from the ASP.NET MVC OldController to NewController

8) Copy the About.cshtml, Contact.cshtml, and Index.cshtml Razor view files from the ASP.NET MVC project to the ASP.NET Core project.

9) Run the ASP.NET Core app and test each method.

10) For static content Add a Bower configuration file named bower.json to the project root (Right-click on the project, and then Add > New Item > Bower Configuration File). Add Bootstrap and jQuery to the file

11) Copy the favicon.ico file from the old MVC project to the wwwroot folder in the ASP.NET Core project.

12) Copy the _ViewStart.cshtml file from the old ASP.NET MVC project's Views folder into the ASP.NET Core project's Views folder. The _ViewStart.cshtml file has not changed in ASP.NET Core MVC.

13) Create a Views/Shared folder.

14) Copy the _Layout.cshtml file from the old ASP.NET MVC project's Views/Shared folder into the ASP.NET Core project's Views/Shared folder.

15) Change some old features on razor view with news like followings

• Replace @Styles.Render("~/Content/css") with a <link> element to load bootstrap.css
• Remove @Scripts.Render("~/bundles/modernizr"). Comment out the @Html.Partial("_LoginPartial") line (surround the line with @*...*@).
• Replace @Scripts.Render("~/bundles/jquery") with a <script> element.
• Replace @Scripts.Render("~/bundles/bootstrap") with a <script> element.