Partager via

Migrer de .NET Framework 1.1, 2.0 et 3.5 vers .NET Framework 4

Windows ne prend plus en charge .NET Framework 1.1 et 2.0. Par conséquent, les applications qui ciblent les anciennes versions de .NET Framework ne s’exécutent pas sans installer explicitement .NET Framework 3.5. Toutefois, il est recommandé de mettre à niveau l’application vers .NET Framework 4. Cet article décrit les étapes requises pour exécuter une application qui cible une ancienne version .NET Framework.

Recibler ou recompiler

Il existe deux façons d’obtenir une application compilée à l’aide de .NET Framework 1.1 pour s’exécuter sur Windows 7 ou un système d’exploitation Windows ultérieur :

  • Reciblez l’application pour qu’elle s’exécute sous .NET Framework 4 et versions ultérieures.

    Le reciblage nécessite que vous ajoutiez un élément <supportedRuntime> u fichier de configuration de l'application qui lui permet de s'exécuter sous .NET Framework 4 et versions ultérieures.

    Le fichier de configuration d’une application est un fichier XML qui se trouve dans le même répertoire et a le même nom de fichier que l’application, mais avec une .config extension. Par exemple, pour une application nommée MyExecutable.exe, le fichier de configuration de l’application est nommé MyExecutable.exe.config.

    Ce fichier de configuration prend la forme suivante :

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

  • Recompilez l’application avec un compilateur qui cible .NET Framework 4 ou une version ultérieure. Si vous avez initialement utilisé Visual Studio 2003 pour développer et compiler votre solution, vous pouvez ouvrir la solution dans Visual Studio 2010 (et éventuellement les versions ultérieures également) et utiliser la boîte de dialogue Compatibilité de projet pour convertir la solution et les fichiers projet des formats utilisés par Visual Studio 2003 au format Microsoft Build Engine (MSBuild).

    Que vous préfériez recompiler ou recibler votre application, vous devez déterminer si votre application est affectée par les modifications introduites dans les versions ultérieures de .NET Framework. Ces modifications sont de deux types :

  • Changements cassants qui se sont produits entre .NET Framework 1.1 et les versions ultérieures du .NET Framework.

  • Types et membres de type marqués comme déconseillés ou obsolètes entre .NET Framework 1.1 et versions ultérieures de .NET Framework.

Si vous reciblez ou recompilez votre application, vous devez examiner à la fois les changements cassants et les types et membres obsolètes pour chaque version du .NET Framework commercialisée après .NET Framework 1.1.

Modifications majeures

Lorsqu'une modification avec rupture se produit, selon la modification spécifique, une solution de contournement peut être disponible pour les applications reciblées et recompilées. Dans certains cas, vous pouvez ajouter un élément enfant à l’élément <runtime> du fichier de configuration de votre application pour restaurer le comportement précédent. Par exemple, le fichier de configuration suivant restaure le comportement de tri et de comparaison de chaînes utilisé dans .NET Framework 1.1 et peut être utilisé avec une application retargetée ou recompilée.

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

Toutefois, dans certains cas, vous devrez peut-être modifier votre code source et recompiler votre application.

Pour évaluer l'impact de modifications avec rupture possibles sur votre application, vous devez passer en revue les listes suivantes de modifications :

Types et membres obsolètes

L’impact des types et membres déconseillés est un peu différent pour les applications retargetées et les applications recompilées. L’utilisation de types et de membres obsolètes n’affecte pas une application retargetée, sauf si le type ou le membre obsolète a été physiquement supprimé de son assembly. Recompiler une application qui utilise des types ou des membres obsolètes génère généralement un avertissement du compilateur plutôt qu’une erreur de compilateur. Toutefois, dans certains cas, il génère une erreur de compilateur, et le code qui utilise le type ou le membre obsolète ne se compile pas correctement. Dans ce cas, vous devez réécrire le code source qui appelle le type ou le membre obsolète avant de recompiler votre application. Pour plus d’informations sur les types et les membres obsolètes, consultez What’s Obsolete in the Class Library.

Pour évaluer l’impact des types et des membres qui ont été dépréciés depuis la publication de .NET Framework 2.0 SP1, consultez What’s Obsolete in the Class Library. Passez en revue les listes des types et membres obsolètes pour .NET Framework 2.0 SP1, .NET Framework 3.5 et .NET Framework 4.

  • Last updated on