Puneet Ghanshani

Chief Architect at Microsoft

11 minute read

Microsoft launched .NET 4.5 in 2012 and later added an upgrade to .NET 4.5.1 in Dec, 2013.  So considering the timelines, there has been over an year that .NET 4.5 has been launched.  It means .NET 4.5.x has been tested thoroughly (by general public/developers), bugs have been identified and fixed and hence should be an easy upgrade for enterprise applications.

Upgrading to .NET 4.5.x may be very tempting to developers due to several reasons (many times IDE specific); however, its important to evaluate the waters before jumping in.  In this article, let’s see some of the areas that you would want to consider before upgrading your application suite to .NET 4.5.x

Environment Accessibility and Support

First thing to check before planning any development or upgrade activity is whether your production (or ‘live’) environment supports installation of .NET 4.5.x framework.  Some of checks that you should do before committing to upgrade are -

  • Certification and Packaging of .NET 4.5.x framework – Organizations (specially those concerned about security) tend to test and certify application suites before re-packaging (setup files) them so that applications/framework can be installed on desktop / servers in an automated way.  This does not mean that the original packaging (setup) was not done efficiently.  The re-packaging is done to ensure standardization in installation process. 
  • Mechanism to promote / install framework upgrades - Considering that the product life cycle has reduced it is important to know how much time the packaging team would require to re-packaging updates and promote them.

If your application is a n-tier web application (ASP.NET WebForms / MVC), you need to check your hardware capabilities

  • Supported Physical / Virtual infrastructure – .NET frameworks do not require more than 512 MB RAM.

    But for server applications, .NET 4.5.x requires Windows Server 2012 as operating system.  Windows Server 2012, for its smooth operation, requires 2GB RAM (recommended: 8GB) with 1.3 Ghz single 64-bit core processor.  So there is a dependency on availability of Windows Server 2012 packaging in your organization.

    .NET 4.5 needs a Windows Server 2008 variant and requires lesser hardware capabilities to run your application efficiently.  If you are not using any of these server operating systems, or are not on 64-bit architecture you will not be able to leverage the capabilities of .NET 4.5.x and will have to restrict your upgrades to .NET 4.0

If your application is a desktop application, there are several constraints to upgrade to a newer framework as you have several production machines (each desktop).  Unless you have a strategy to push .NET 4.5.x to all desktops, you shouldn’t think of upgrading your framework.

Understand the upgrade

No, I am not referring to understand the features of .NET 4.5.x.  I’ll talk about that in the next part of this article.  Here I am referring to how .NET 4.5.x fits in Microsoft’s release schema.  Until now, for every .NET framework release there has been a new folder created in %windir%\Microsoft.NET\Framework

In case of .NET 4.5.x, it is not the case.  When you install .NET 4.0,  the installer creates v4.0 folder.  When you install .NET 4.5.x, it updates the assemblies in v4.0 folder.  So in a way, .NET 4.5.x is not just an upgrade to .NET 4.0 but a replacement (with enhancements.) So unless you actually refer to registry keys you would not come to know if .NET 4.5.x is installed on your machine. Refer to MSDN article for more details on this.

image

What this means to a developer?

Simple.  You can not have disparate installations on developer’s machine and your deployment machines (system integration, QA, user acceptance, parallel production, production, DR, etc.) Let’s understand why.

Let’s assume that a developer has .NET 4.5.1 installed on his machine with VS 2013 as IDE.  The system integration environment has also been upgraded but others have not been upgraded yet.  Let’s say your code is still using .NET 4.0 and you trigger a build on your development machine for a production release.  What would happen here is that your build will use references of new assemblies installed in v4.0 folder (mentioned above.)  When this code gets packaged (on your machine) and is deployed in a non-upgraded environment, it may give you some runtime errors as it does not find .NET 4.5.x assemblies in GAC. 

So it’s necessary to understand the impact of this upgrade. 

Process Automation – Continuous Integration

Well, we understood the impact of the upgrade in the previous section.  The solution to above problem lies in creating an isolated environment that resembles the non-upgraded environment.  The Build Automation Environment.  There are two ways to resolve this without having a DLL Hell -

  1. Keep the build environment on .NET 4.0 so that you can trigger the builds using plain vanilla .NET 4.0 framework instead of .NET 4.5.x assemblies
  2. If you still upgrade this environment to .NET 4.5.x, you will need to alter the MSBuild targets to use

    C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0
    instead of
    %windir%\Microsoft.NET\Framework\v4.0

    This would ensure that the output of your build automation works for .NET 4.0 / 4.5.x.

Application level breaking changes

Not many, but there are a few breaking changes.  To validate this, you can check for file size of System.Runtime.Serialization.dll in two folders.  The Reference Assemblies (in Program Files folder) are the original framework assemblies and the Framework folder (in Windows directory) are the replaced assemblies if .NET 4.5.x is installed.

C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.0\
and
C:\Windows\Microsoft.net\Framework\v4.0.30319\

Why is this radical change in the way .NET worked?  Earlier to .NET 4.0, reference assemblies were a direct copy of GAC assemblies.  That means with every minor upgrade, you can unknowingly use a newer assembly.  And this program would fail on an unpatched machine.  To resolve this, in .NET 4.0 Reference Assemblies (in Program Files folder) act as redirecting assemblies and have only metadata.  They do not have IL code as it is moved to base .NET framework (mscorlib).

So in a nutshell, .NET 4.5 does not have its own independent CLR.  If you have different .NET frameworks installed on different machines using same CLR, you will have to test your application under these breaking changes. 

Refer to MSDN article on .NET 4.5 breaking changes and .NET 4.5.x breaking changes.  One of the problem, often faced, is serialization exception

Common Language Runtime detected an invalid program.

The easiest technique to fix this issue without changing any code is to add following block in the configuration

  1. <configuration>
  2.   <system.xml.serialization>
  3.     <xmlSerializer useLegacySerializerGeneration="true"/>
  4.   </system.xml.serialization>
  5. </configuration>

 

What happens to .NET version on IIS hosted websites?


When installing Web Server Role (IIS), you need to explicitly select the versions on ASP.NET you want to support.

image

By default, the wizard will create following Application Pools

image

Please note the .NET framework version for ASP.NET v4.5 is v4.0.

Hope this helps in taking an informed decision of upgrade and its impact.

You May Also Enjoy