.NET Framework Application Upgrade Strategies


Starting with the premise most companies are running a variety of Microsoft .NET Framework 1.0 and 1.1 ASP.NET applications and would like to standardize on ASP.NET 2.0 running on the .NET Framework 2.0. This document outlines options available for either upgrading the existing applications, or allowing them to run side-by-side targeting their respective runtimes.

Note: The .NET Framework was designed to run side-by-side, and not only is this recommended, it is required under certain scenarios.

1.1         Version Comparisons

In order to identify which applications should be upgraded, or left running against their current .NET Framework version, the relative benefits an application could realise for each .NET Framework version should be examined.

1.1.1           .NET Framework Version 1.0

The .NET Framework was released in February 2001 to address several key developer challenges:

·         Memory allocation/de-allocation and data type/size adherence by providing a “safe” managed runtime environment.

·         Replace tightly coupled largely non scalable communication mechanisms with loosely coupled scalable public Internet protocols and standards (i.e. Web Services and XML Serialization).

·         Eliminate “DLL Hell” through assembly and run time versioning. 

·         Unifying disparate class libraries, object models and API’s into a language agnostic intuitive hierarchical object model.

The first goal was to provide a “safe” runtime environment. Having a runtime environment enabled developers to let a runtime clean up memory/objects/handles etc. The word “safe” in this context indicates developers do not need to worry about accidental data type mismatches or memory overrun conditions – situations that can be very difficult to diagnose and potentially expose assets to risk. Another issue historically facing developers was the need for cross application communication but in a loosely coupled way, followed by solutions for versioning issues and a language agnostic object library.

1.1.2           .NET Framework Version 1.1

Microsoft .NET Framework Version 1.1[1] was a relatively minor release and primarily focused on security, mobile devices, adding some data access providers, and stricter language enforcement.

The primary enhancements from .NET Framework version 1.0 to 1.1 were around security and data access providers, so if the application is not susceptible to attacks, or is needing to use the additional data providers the application may still realize a nominal performance gain.

The performance gain may not outweigh the development and testing effort needed to correct any code not complying with the stricter language enforcements or changes in the garbage collection algorithms. There is a list[2] that documents all issues that would prevent a .NET Framework 1.0 application from targeting the .NET Framework 1.1. 

1.1.3           .NET Framework Version 2.0

Microsoft .NET Framework Version 2.0[3] marked several significant improvements over versions 1.0 and 1.1. The key benefits are listed as follows:

·         Performance.

·         Enhanced Web development experience through improved designers and additional controls.

·         Language enhancements.

·         Deploying and updating Windows applications over the internet.

·         Application Lifecycle Tools.

·         64 bit compilation.

Any software that sees significant enhancement will potentially have some backward compatibility issues and the .NET Framework 2.0 is no exception. Microsoft Australia, has overseen the upgrade of ~20 Australian .NET Framework 1.1 applications to the .NET Framework 2.0, amounting to over 10 million lines of code. None of these applications required significant change, and in some cases the applications realised a ~10% performance increase.

While this strategy can yield performance gains and may eliminate the requirement for an additional .NET Framework runtime version on the server, it unfortunately doesn’t deliver many of the benefits of a full upgrade, such as:

·         64 bit support – not an issue where the application is not to be run on a 64 bit server. 

·         Access to the 70 new web controls – not an issue where not utilising the new features.

·         Access to the new Visual Studio 2005 designers – not an issue where the application is not being enhanced.

·         Access to the Lifecycle tools such as Class Diagrams, Architectural diagrams, Unit tests, etc., available within Visual Studio Team System.

Microsoft provides detailed documentation[4] on the .NET Framework 1.1 to 2.0 upgrade process, strategies and application load mechanisms employed.

1.2         Upgrade Options

There are three different approaches to consider going forward, all of which are fully supported by Microsoft:

·         Side-by-side – This involves having the application running unaltered on its original version of the .NET Framework, with all versions of the .NET Framework running side-by-side. No changes are required to the existing application to support this.

·         Configuration – This involves changing the configuration for an application targeting the usage of a specified .NET Framework versus the version originally compiled against. Changes may be required where the existing application uses features that are not longer supported or the expected functionality has changed. Additional effort would be required to perform a full regression test to verify the application.

·         Upgrade – This involves upgrading the application project and recompiling against the specified .NET Framework. Changes may be required where the existing application uses features that are not longer supported or the expected functionality has changed. Additional effort would be required to perform a full regression test to verify the application.

An MSDN compatibility article[5] is available that covers all of the above scenarios and details the best practices for testing a managed application or component for compatibility with newer runtime versions. It covers different configurations you should test to ensure that the application continues to run properly.

In evaluating whether upgrades should occur or not, the following should be considered:

·         Are there any issues related to having multiple runtimes within an operating environment; there are no technical issues from a .NET Framework perspective.

·         There will be an increased support matrix for each runtime, therefore, a cost/benefit analysis should be considered to determine whether the cost associated with any upgrade provides significant benefit to warrant the effort of upgrade and full regression test.

·         Having multiple runtimes implies that developers will need access to the associated Visual Studio IDE (2002, 2003 and 2005) to support the corresponding runtime. Are there any issues surrounding the installation/distribution of development environments with these tools.

From a guideline perspective, Microsoft recommends, for applications destined for major revisions or enhancements a full upgrade should be evaluated. For applications not undergoing major revisions going forward the application should be tested if it will run under the latest runtime, if not they should remain on their current .NET Framework version/runtime.



[1] MSDN .NET Framework 1.1 – http://msdn.microsoft.com/netframework/technologyinfo/overview/whatsnew/default.aspx

[1] MSDN .NET 1.0 to 1.1 incompatibilities – http://www.gotdotnet.com/team/changeinfo/Backwards1.0to1.1/default.aspx

[1] MSDN .NET Framework 2.0 – http://msdn2.microsoft.com/en-us/library/t357fb32.aspx

[1] MSDN .NET 2.0 upgrade – http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetdep/html/netfxcompat.asp

[1] MSDN Compatibility – http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetdep/html/netfxcompatapptest.asp