Compartir a través de

Migración de .NET Framework 1.1, 2.0 y 3.5 a .NET Framework 4

Windows ya no admite .NET Framework 1.1 y 2.0. Como resultado, las aplicaciones que tienen como destino versiones anteriores de .NET Framework no se ejecutarán sin instalar explícitamente .NET Framework 3.5. Sin embargo, se recomienda actualizar la aplicación a .NET Framework 4. En este artículo se describen los pasos necesarios para ejecutar una aplicación que tenga como destino una versión anterior de .NET Framework.

Redirigir o recompilar

Hay dos maneras de obtener una aplicación compilada mediante .NET Framework 1.1 para ejecutarse en Windows 7 o en un sistema operativo Windows posterior:

  • Vuelva a configurar la aplicación para que se ejecute en .NET Framework 4 y versiones posteriores.

    Para redestinarla, es necesario agregar un elemento <supportedRuntime> al archivo de configuración de la aplicación que permita ejecutarla en .NET Framework 4 y versiones posteriores.

    El archivo de configuración de una aplicación es un archivo XML que se encuentra en el mismo directorio y tiene el mismo nombre de archivo que la aplicación, pero con una .config extensión. Por ejemplo, para una aplicación denominada MyExecutable.exe, el archivo de configuración de la aplicación se denomina MyExecutable.exe.config.

    Este archivo de configuración tiene la siguiente forma:

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

  • Vuelva a compilar la aplicación con un compilador que tenga como destino .NET Framework 4 o una versión posterior. Si originalmente usó Visual Studio 2003 para desarrollar y compilar la solución, puede abrir la solución en Visual Studio 2010 (y, posiblemente, versiones posteriores) y usar el cuadro de diálogo Compatibilidad del proyecto para convertir los archivos de solución y proyecto de los formatos usados por Visual Studio 2003 al formato Microsoft Build Engine (MSBuild).

    Independientemente de si prefiere volver a compilar o volver a configurar la aplicación, debe determinar si la aplicación se ve afectada por los cambios introducidos en versiones posteriores de .NET Framework. Estos cambios son de dos tipos:

  • Cambios importantes que se produjeron entre .NET Framework 1.1 y versiones posteriores de .NET Framework.

  • Tipos y miembros de tipo que han sido marcados como desaprobados o obsoletos entre .NET Framework 1.1 y las versiones posteriores de .NET Framework.

Tanto si redestina la aplicación como si vuelve a compilarla, deberá revisar los cambios importantes y los miembros y tipos obsoletos de cada versión de .NET Framework publicada después de .NET Framework 1.1.

Cambios críticos

Cuando se produce un cambio importante, dependiendo del cambio específico, es posible que haya una solución alternativa disponible tanto para las aplicaciones redirigidas como para las recompiladas. En algunos casos, puede agregar un elemento secundario al <elemento en tiempo de ejecución> del archivo de configuración de la aplicación para restaurar el comportamiento anterior. Por ejemplo, el siguiente archivo de configuración restaura el comportamiento de comparación y ordenación de cadenas usado en .NET Framework 1.1 y se puede usar con una aplicación reorientada o recompilada.

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

Sin embargo, en algunos casos, es posible que tenga que modificar el código fuente y volver a compilar la aplicación.

Para evaluar el impacto de los posibles cambios importantes en la aplicación, debe revisar las siguientes listas de cambios:

Tipos y miembros obsoletos

El impacto de los tipos y miembros desusados es ligeramente distinto en las aplicaciones redestinadas que en las aplicaciones compiladas de nuevo. El uso de tipos obsoletos y miembros no afectará a una aplicación redirigida a menos que el tipo o miembro obsoleto se haya quitado físicamente de su ensamblaje. Al volver a compilar una aplicación que usa tipos obsoletos o miembros, normalmente se genera una advertencia del compilador en lugar de un error del compilador. Sin embargo, en algunos casos, genera un error del compilador y el código que usa el tipo obsoleto o el miembro no se compila correctamente. En este caso, debe reescribir el código fuente que invoca al tipo o miembro obsoleto antes de volver a compilar la aplicación. Para obtener más información sobre los tipos y miembros obsoletos, vea ¿Qué está obsoleto en la biblioteca de clases?

Para evaluar el impacto de los tipos y miembros que han quedado en desuso desde la versión de .NET Framework 2.0 SP1, consulte ¿Qué está obsoleto en la biblioteca de clases? Revise las listas de tipos y miembros obsoletos para .NET Framework 2.0 SP1, .NET Framework 3.5 y .NET Framework 4.