Events
Mar 17, 11 PM - Mar 21, 11 PM
Join the meetup series to build scalable AI solutions based on real-world use cases with fellow developers and experts.
Register nowThis browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
Windows no longer supports .NET Framework 1.1 and 2.0. As a result, applications that target older .NET Framework versions won't run without explicitly installing .NET Framework 3.5. However, it's recommended that you upgrade the app to .NET Framework 4. This article discusses the steps required to run an application that targets an old version .NET Framework.
There are two ways to get an application that was compiled using .NET Framework 1.1 to run on Windows 7 or a later Windows operating system:
Retarget the application to run under .NET Framework 4 and later versions.
Retargeting requires that you add a <supportedRuntime> element to the application's configuration file that allows it to run under .NET Framework 4 and later versions.
The configuration file for an app is an XML file that's in the same directory and has the same file name as the app, but with a .config extension. For example, for an app named MyExecutable.exe, the application configuration file is named MyExecutable.exe.config.
Such a configuration file takes the following form:
<configuration>
<startup>
<supportedRuntime version="v4.0"/>
</startup>
</configuration>
Recompile the application with a compiler that targets .NET Framework 4 or a later version. If you originally used Visual Studio 2003 to develop and compile your solution, you can open the solution in Visual Studio 2010 (and possibly later versions too) and use the Project Compatibility dialog box to convert the solution and project files from the formats used by Visual Studio 2003 to the Microsoft Build Engine (MSBuild) format.
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 .NET Framework. These changes are of two kinds:
Breaking changes that occurred between .NET Framework 1.1 and later versions of .NET Framework.
Types and type members that have been marked as deprecated or obsolete between .NET Framework 1.1 and later versions of .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 .NET Framework that was released after .NET Framework 1.1.
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 .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:
Breaking Changes in .NET Framework 2.0 documents changes in .NET Framework 2.0 SP1 that can affect an application that targets .NET Framework 1.1.
Changes in .NET Framework 3.5 SP1 documents changes between .NET Framework 3.5 and .NET Framework 3.5 SP1.
.NET Framework 4 Migration Issues documents changes between .NET Framework 3.5 SP1 and .NET Framework 4.
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 Class Library.
To assess the impact of types and members that have been deprecated since the release of .NET Framework 2.0 SP1, see What's Obsolete in the Class Library. Review the lists of obsolete types and member for .NET Framework 2.0 SP1, .NET Framework 3.5, and .NET Framework 4.
.NET feedback
.NET is an open source project. Select a link to provide feedback:
Events
Mar 17, 11 PM - Mar 21, 11 PM
Join the meetup series to build scalable AI solutions based on real-world use cases with fellow developers and experts.
Register nowTraining
Module
Modernize ASP.NET Framework to ASP.NET Core with the .NET Upgrade Assistant - Training
In this module, you'll learn to when, why, and how to modernize an ASP.NET Framework app to ASP.NET Core using the Upgrade Assistant.