Upgrading to ASP.NET 5 involved installing the new Visual Studio 2015. This was actually a very smooth update process, and the solutions and projects (built before using Visual Studio 2013) opened without any messages about having to run conversions.

In fact, the only changes we noticed was a new (hidden) folder added to our solution folder called .vs, which stores project related information to avoid polluting the root, a highly requested feature. Files in this folder, such as the solution user options (.suo) and applicationhost.config for IISExpress are automatically generated and are specific to the local development environment, so we added the folder to the source repository ignore list to prevent annoying other developers in the team.

Upgrading projects from .NET 4.5 to .NET 4.6 (and then back again)

After installing VS2015, the next step was to upgrade our existing projects to target the .NET 4.6 framework, which has a number of benefits such as new language features, performance gains in the new 64 bit Just-In-Time (JIT) compiler ‘RyuJIT’, support for HTTP/2, enhancements to garbage collection, cryptography updates and more.

This step isn’t required if you plan to move straight to .NET Core 5 as it’s a completely different framework altogether, but it seemed like a sensible thing to do for us as it’s going to take quite a while to upgrade all our projects to target .NET Core 5 (Core CLR) and luckily ASP.NET 5 can work alongside code libraries written for the current .NET framework (CLR). The general advice seems to be if you’re migrating an existing project, go with ASP.NET 5 running on the regular CLR. If, however, you’re starting a brand new project, go with .NET Core 5 as all the constraints will be worked out at the start and will be less painful than migrating the project later on.

After upgrading all the projects to target .NET 4.6, we’ve since rolled back the changes due to a nasty bug that the developers over at Stack Overflow discovered. It’s to do with how the new RyuJIT optimises Tail Calls, causing incorrect parameter values to be passed to methods during certain situations. Apparently Microsoft have fixed this internally, but haven’t released the fix yet. Hopefully this will be sorted in the coming weeks though! The next step will be to investigate all the changes required to upgrade our ASP.NET MVC 5 projects.