Risks of the in-place upgrade

When .NET 4.5 is installed, it effectively replaces the existing .NET 4.0 assemblies in the machine; they are overwritten by a newer version.

Curiously, when we query the runtime version, Environment.Version is still 4.0.30319, having differences only in the build numbers. Basically, it becomes hard for the application to identify if we are running .NET 4.0 or 4.5, which might be necessary if we have to decide which part of the code can or cannot be executed.

And yes, we can build an application on .NET 4.5 and execute it on .NET 4.0, but these might not run properly if it uses some features of the .NET 4.5 framework. Otherwise, building .NET 4.0 applications with .NET 4.5 should not bring any problems.

For avoiding these issues, we should use the <supportedruntime> element, which specifies the versions of the CLR supported by the application with a syntax like the following:

<supportedRuntime version="runtime version" sku="sku id"/>

If this is not found on the application configuration file, the runtime version used to build the application will be used. An example of this configuration is the following:

<configuration>
    <startup> 
        <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" />
    </startup>
</configuration>

With this in place, the application will know that it needs .NET 4.5; if it is not installed, our application will not run and propose to install it.

Note that most of the client applications add this automatically, but we must keep an eye out for it or we might be surprised.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset