Upgrading target framework from 4.0 to 4.5 for ASP.NET MVC applications

Recently, I finished upgrading my ASP.NET MVC 4 application(in Visual Studio 2012) from .NET 4.0 to .NET 4.5 framework. Not-so-easy job though. A lot of pain and anxiety is involved when you migrate to a different target framework version and when you know that you have a lot of Nuget package references and use a couple of third-party components that interface with a specific version of .NET framework. So, i thought of sharing my experiences and challenges during this process.

The easiest way to target all projects to .NET 4.5 framework is by doing a search for all *.csproj files and replace <TargetFrameworkVersion>v4.0</TargetFrameworkVersion>  with <TargetFrameworkVersion>v4.5</TargetFrameworkVersion> (or client profile, etc). You would also need to replace the <compilation> element’s targetFramework=”4.0″ with 4.5 in the application’s web.config file.

Issues after migrating ASP.NET MVC solution from .NET 4.0 to .NET 4.5:


  1. The real issue are the NuGet packages, they will just not work, – some have a .NET 4.5 specific version – a good example is Entity Framework. When the project is targeting version 4.0 of the framework and you install/update EF to version 5 you actually end up with EF 4.4 (which doesn’t have support for enum types and so on, targeted for .NET 4.5). When i looked at my project reference, I found the following entry:

                      <Reference Include=“EntityFramework, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089, processorArchitecture=MSIL”>

       The only way to solve this is to remove all packages and install them again, which is a massive pain to do manually and unfortunately the current version of NuGet is not of much help there either.

       Open Visual Studio 2012,

     Go to “Tools” > “Library Package Manager” > “Package Manager Console”. This will open a powershell command prompt,

     then type: uninstall-package EntityFramework for each of the listed projects for the default project dropdown.

       After uninstalling EntityFramework from each of the projects, install EntityFramework by typing “install-package EntityFramework” in the powershell command-prompt.

       NuGet 2.0 doesn’t handle re-targeting your applications very well. In order to change your packages’ target frameworks, you must uninstall and reinstall the packages.

      The reasons why packages must be uninstalled and re-installed are:

    • When installing a package, we determine the target framework of your project
    • We then match that up with the package contents, finding the appropriate \lib\ folder (and \content\ folder)
    • Assembly references are added with Hint Paths that point to the package’s \lib\ folder, with the right subfolder (\lib\net40 for example)
    • Content files are copied from the packages \content\ folder, with the right subfolder (\content\net40 for example)
    • We record the targetFramework used to install the package within the packages.config file
    • After you change your project’s target framework, the Hint Paths still point to net40
    • When you uninstall packages, we check the targetFramework that was recorded in packages.config to see what target framework’s libs/content to remove from your project
    • When you reinstall the package, we detect your updated target framework and reference/copy the right libs/content

2. ELMAH and Ninject work like a charm without any changes. That’s a good news. 

3. Make sure you take a look into this one about the new Date and DateTime editor templates in MVC 4. Also there seem to be model binding changes to do with DateTime . 

4. Lastly, don’t forget to update your test assemblies App.config with the correct assembly redirects if you are running tests against ASP.NET MVC controllers, which use MvcFutures or MvcContrib, because you will end up seeing weird “Type A doesn’t match type A” errors.

Comments (8)

  1. Sameer says:

    good info. 🙂

  2. Nice and helpful info. Thanks….

  3. luke mr says:

    frame work 5.0 to 11.1 version are  initialization'd  and debug can be most fast and easy to use .

        <Reference Include="EntityFramework, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089, processorArchitecture=MSIL">




  4. Anas says:

    Nuget is always sucks. Thanks for your information

  5. Pete says:

    Thanks for this – thought it was just me!

    Microsoft has totally failed on the pledge to end DLL hell with .Net.  Can MS really stay in the game much longer when they're such unmitigated crap at software?

  6. Miguelito says:

    I had this problem, so I'll put some more details for any poor soul that follows this.

    VS 2013

    Solution has windows component and I wanted to have a shared DLL, because they talk to each other

    The problem is that the Windows App was set to 4.51 .Net

    Added the Web project to the solution, but it was 4.0 .Net so could not use the DLL, because it was 4.51

    Error 1

    Some NuGet packages were installed using a target framework different from the current target framework and may need to be reinstalled. For more information, visit docs.nuget.org/…/reinstalling-packages.  

    Packages affected:

    1-Update-Package –reinstall AspNet.ScriptManager.jQuery,

    2-Update-Package –reinstall AspNet.ScriptManager.jQuery.UI.Combined,

    3-fail – Update-Package –reinstall DotNetOpenAuth.Core,

    11-      Update-Package –reinstall DotNetOpenAuth.Core,

    7-Update-Package –reinstall DotNetOpenAuth.OAuth.Consumer,

    8-       Update-Package –reinstall DotNetOpenAuth.OAuth.Core,

    9-Update-Package –reinstall DotNetOpenAuth.OpenId.Core,

    10-Update-Package –reinstall DotNetOpenAuth.OpenId.RelyingParty,

    4-Update-Package –reinstall EntityFramework,

    5-Update-Package –reinstall Microsoft.AspNet.FriendlyUrls.Core,

    6-Update-Package –reinstall Microsoft.AspNet.Membership.OpenAuth

    The numbers are the order reinstalled the NuGet packages.

    Notice it failed at 3, so continued at 4, then went back to the DotNetOpenAuth group.

    Then I got:

    Error 2 The type or namespace name 'DotNetOpenAuth' could not be found (are you missing a using directive or an assembly reference?) C:ProjectysCorrPub_123114CorrMonAccountRegisterExternalLogin.aspx.cs 4 7 CorrMon

    and had to add references to the 6 DotNetOpenAuth DLLs in the bin directory

    It also wanted a new localhost port. I changed that and allowed it to configure the new Virtual Directory.

    It worked, but I need to go a new route… The point of all this is you can Re-install the Nuget packages, but you may need to do the references yourself. Good luck

  7. Miguelito says:

    Per the previous comment… It completely failed. I was never able to update an MVC4 project to .Net 4.51 and I did try. I updated the NuGet application to ver. 2.8, but nothing I did would get the various DotNetOpenAuth assemblies into the project. If you have to do this, good luck, but do not think it can be done because my previous comment suggests it can. … Really, I can do fine without using the common library I was trying to use. I just need about 3 small duplicated classes in each project. The MVC project will remain .Net 4.0. If you think about it, how much overlap is there going to be between most Windows and Web applications?