The updates in the .NET Framework provide many improvements, including support for new language features in c#, garbage collection, enhancements in cryptography support, feature toggles, new classes in the BCL and others. The RyuJIT compiler adds significant performance gains for 64bit applications, even those not originally targeting the 4.6, improves startup times and can reduce the memory footprint of your application.
While the explicit modification of your projects may not be required to gain some of the 4.6 benefits, there may be other organizational factors that lead you down that path. We’ll work through the mechanics of the upgrade to 4.6 in this post.
Upgrading Your ASP.NET Projects
Every project we create references a specific version of the .NET Framework. This has been true throughout the history of .NET, and though the way we will do it in the future will change with the new project system, the premise remains the same.
For now, you can simply open the properties tab for your project and change the target Framework.
You will be prompted to let you know that some changes may be required.
Now, if you were to try to build the Bootcamp project when you’re only partway through the upgrade, you’d see something similar to the following:
With a message that reads:
“The primary reference “x” could not be resolved because it was built against the “.NETFramework,Version=v4.6” framework. The is a higher version than the currently targeted framework “.NETFramework,Version=4.5.1”.”
You may run into this in other scenarios, as well, especially if you you have references to packages or libraries that get out of sync in your upgrade process. A project that takes on dependencies must be at (or higher than) the target framework of the compiled dependencies. To remedy this, we simply need to complete the upgrade process on the rest of the projects.
Moving from 4.5.x to 4.6 is not a required step in our conversion to an MVC 6 project. In fact, MVC 6 indeed runs on a different framework altogether. To that end, any environment where you have 4.6 installed will “pull up” other assemblies because it is a drop-in replacement for pervious versions.
Perhaps your primary motivator to move to 4.6 is the perf bump in the runtime, or it might be the new language features (which only require a framework install, not a version bump in your target). But it also ensures we’re compatible with other projects in our organization, particularly when we consider the default target for new projects in VS 2015 is against 4.6. If we want to leverage these from other projects in our organization, we want to make sure that we’re not the lowest common denominator in the mix.