Share via

Migrating from the .NET Framework Version 1.1

  • Article

Windows 7 does not support the .NET Framework version 1.1. As a result, applications that target the .NET Framework 1.1 will not run without modification on Windows 7. This topic discusses the steps required to run an application that targets the .NET Framework 1.1 under Windows 7.

Retargeting or Recompiling

There are two ways to get an application that was compiled using the .NET Framework 1.1 to run on Windows 7:

  • You can retarget the application to run under .NET Framework version 4. Retargeting requires that you add a <supportedRuntime> element to the application's configuration file that allows it to run under .NET Framework 4. Such a configuration file takes the following form:

    <configuration> 
   <startup>
      <supportedRuntime version="v4.0"/>
   </startup>
</configuration>

  • You can recompile the application with a compiler that targets the .NET Framework 4. If you originally used Visual Studio 2003 to develop and compile your solution, you can open the solution in Visual Studio 2010, and the Visual Studio Conversion Wizard will convert the solution and project files from the formats used by Visual Studio 2003 to the Microsoft Build Engine (MSBuild) format used by Visual Studio 2010.

Regardless of whether you prefer to recompile or retarget your application, you must determine whether your application is affected by any changes introduced in later versions of the .NET Framework. These changes are of two kinds:

  • Breaking changes that occurred between the .NET Framework 1.1 and later versions of the .NET Framework.

  • Types and type members that have been marked as deprecated or obsolete between the .NET Framework 1.1 and later versions of the .NET Framework.

Whether you retarget your application or recompile it, you should review both the breaking changes and the obsolete types and members for each version of the .NET Framework that was released after .NET Framework 1.1.

Breaking Changes

When a breaking change occurs, depending on the specific change, a workaround may be available both for retargeted and recompiled applications. In some cases, you can add a child element to the <runtime> element of your application's configuration file to restore the previous behavior. For example, the following configuration file restores the string sorting and comparison behavior used in the .NET Framework 1.1 and can be used either with a retargeted or a recompiled application.

<configuration>
   <runtime>
      <CompatSortNLSVersion enabled="4096"/>
   </runtime>
</configuration>

However, in some cases, you may have to modify your source code and recompile your application.

To assess the impact of possible breaking changes on your application, you must review the following lists of changes:

Obsolete Types and Members

The impact of deprecated types and members is somewhat different for retargeted applications and recompiled applications. The use of obsolete types and members will not affect a retargeted application unless the obsolete type or member has been physically removed from its assembly. Recompiling an application that uses obsolete types or members usually produces a compiler warning rather than a compiler error. However, in some cases, it produces a compiler error, and code that uses the obsolete type or member does not compile successfully. In this case, you must rewrite the source code that calls the obsolete type or member before you recompile your application. For more information about obsolete types and members, see What's Obsolete in the .NET Framework.

To assess the impact of types and members that have been deprecated since the release of the .NET Framework 2.0 SP1, see What's Obsolete in the .NET Framework. Review the lists of obsolete types and member for the .NET Framework 2.0 SP1, the .NET Framework 3.5, and the .NET Framework 4.