Partager via

Vue d’ensemble du portage de .NET Framework vers .NET

  • Article

Cet article fournit une vue d’ensemble de ce que vous devez prendre en compte lors du portage de votre code de .NET Framework vers .NET (anciennement nommé .NET Core). Le portage vers .NET à partir de .NET Framework pour de nombreux projets est relativement simple. La complexité de vos projets détermine la quantité de travail que vous allez effectuer après la migration initiale des fichiers projet.

Les projets où le modèle d’application est disponible dans .NET (comme les bibliothèques, les applications console et les applications de bureau) nécessitent généralement peu de modifications. Les projets qui nécessitent un nouveau modèle d’application, comme le passage vers ASP.NET Core de ASP.NET, nécessitent davantage de travail. De nombreux modèles de l’ancien modèle d’application ont des équivalents qui peuvent être utilisés pendant la conversion.

Technologies de bureau Windows

De nombreuses applications créées pour .NET Framework utilisent une technologie de bureau telle que Windows Forms ou Windows Presentation Foundation (WPF). Les deux Windows Forms et WPF ont été portés vers .NET, mais ils restent des technologies Windows uniquement.

Avant de migrer une application Windows Forms ou WPF, tenez compte des dépendances suivantes :

  1. Les fichiers projet pour .NET utilisent un format différent du .NET Framework.
  2. Votre projet peut utiliser une API qui n’est pas disponible dans .NET.
  3. Les bibliothèques et les contrôles tiers n’ont peut-être pas été portés vers .NET et restent disponibles uniquement pour .NET Framework.
  4. Votre projet utilise une technologie qui n’est plus disponible dans .NET.

.NET utilise les versions open source de Windows Forms et WPF et inclut des améliorations par rapport à .NET Framework.

Pour obtenir des didacticiels sur la migration de votre application de bureau vers .NET 6, consultez l’un des articles suivants :

API spécifiques à Windows

Les applications peuvent toujours P/Invoke les bibliothèques natives sur les plateformes prises en charge par .NET. Cette technologie ne se limite pas à Windows. Toutefois, si la bibliothèque que vous référencez est spécifique à Windows, par exemple un user32.dll ou unkernel32.dll, le code fonctionne uniquement sur Windows. Pour chaque plateforme sur laquelle vous souhaitez que votre application s’exécute, vous devez rechercher des versions spécifiques à la plateforme ou rendre votre code suffisamment générique pour qu’il s’exécute sur toutes les plateformes.

Lors du portage d’une application de .NET Framework vers .NET, votre application a probablement utilisé une bibliothèque fournie avec le .NET Framework. De nombreuses API disponibles dans .NET Framework n’ont pas été transférées vers .NET, car elles s’appuyaient sur des technologies spécifiques à Windows, telles que le Registre Windows ou le modèle de dessin GDI+.

Le pack de compatibilité Windows fournit une grande partie de la surface de l’API .NET Framework à .NET et est fourni via le package NuGet Microsoft.Windows.Compatibility.

Pour plus d’informations, consultez Utiliser le pack de compatibilité Windows pour porter le code vers .NET.

Mode de compatibilité du .NET Framework

Le mode de compatibilité .NET Framework a été introduit dans .NET Standard 2.0. Ce mode de compatibilité permet aux projets .NET Standard et .NET 5+ (et .NET Core 3.1) de référencer des bibliothèques .NET Framework sur Windows uniquement. Le référencement de bibliothèques .NET Framework ne fonctionne pas pour tous les projets, par exemple si la bibliothèque utilise des API WPF (Windows Presentation Foundation), mais cela débloque de nombreux scénarios de portage. Pour plus d’informations, consultez Analyser vos dépendances pour porter le code du .NET Framework vers .NET.

Technologies non disponibles

Il existe quelques technologies dans .NET Framework qui n’existent pas dans .NET :

  • Domaines d'application

    La création de domaines d’application supplémentaires n’est pas prise en charge. Pour l’isolation du code, utilisez des processus ou des conteneurs distincts comme alternative.

  • Communication à distance

    La communication à distance est utilisée pour communiquer entre les domaines d’application qui ne sont plus pris en charge. Pour une communication simple entre les processus, envisagez les mécanismes de communication entre processus (IPC) comme alternative à la communication à distance, telle que les classes System.IO.Pipes ou MemoryMappedFile . Pour les scénarios plus complexes, envisagez des frameworks tels que StreamJsonRpc ou ASP.NET Core (à l’aide des services d’API web gRPC ou RESTful).

  • Sécurité d’accès du code (CAS)

    CAS était une technique de bac à sable prise en charge par .NET Framework, mais déconseillée dans .NET Framework 4.0. Elle a été remplacée par Transparence de la sécurité et n’est pas prise en charge dans .NET. Utilisez plutôt les limites de sécurité fournies par le système d’exploitation, telles que la virtualisation, les conteneurs ou les comptes d’utilisateur.

  • Transparence de la sécurité

    À l’instar du CAS, cette technique de bac à sable n’est plus recommandée pour les applications .NET Framework et n’est pas prise en charge dans .NET. Utilisez plutôt les limites de sécurité fournies par le système d’exploitation, telles que la virtualisation, les conteneurs ou les comptes d’utilisateur.

  • System.EnterpriseServices

    System.EnterpriseServices (COM+) n’est pas pris en charge dans .NET.

  • Windows Workflow Foundation (WF)

    WF n’est pas pris en charge dans .NET 5+ (y compris .NET Core). Pour obtenir une alternative, consultez CoreWF.

Pour plus d’informations sur ces technologies non prises en charge, consultez Technologies .NET Framework indisponibles sur .NET Core et .NET 5+.

Multiplateforme

.NET (anciennement .NET Core) est conçu pour être multiplateforme. Si votre code ne dépend pas de technologies spécifiques à Windows, il peut s’exécuter sur d’autres plateformes telles que macOS, Linux et Android. Cela inclut les types de projets tels que :

  • Bibliothèques
  • Outils basés sur la console
  • Automatisation
  • Sites ASP.NET

.NET Framework est un composant Windows uniquement. Lorsque votre code utilise des technologies ou des API spécifiques à Windows, telles que Windows Forms et Windows Presentation Foundation (WPF), le code peut toujours s’exécuter sur .NET, mais il ne s’exécute pas sur d’autres systèmes d’exploitation.

Il est possible que votre bibliothèque ou votre application basée sur la console puisse être utilisée sur plusieurs plateformes sans beaucoup changer. Lors du portage vers .NET, vous pouvez prendre cela en compte et tester votre application sur d’autres plateformes.

L’avenir de .NET Standard

.NET Standard est une spécification officielle des API .NET qui sont disponibles sur plusieurs implémentations de .NET. La motivation derrière .NET Standard consistait à établir une meilleure uniformité dans l’écosystème .NET. À partir de .NET 5, une approche différente pour établir l’uniformité a été adoptée. Cette nouvelle approche élimine la nécessité d’utiliser .NET Standard dans de nombreux scénarios. Pour plus d’informations, consultez .NET 5 et .NET Standard.

.NET Standard 2.0 a été la dernière version à prendre en charge .NET Framework.

Outils pour faciliter le portage

Au lieu de porter manuellement une application de .NET Framework vers .NET, vous pouvez utiliser différents outils pour automatiser certains aspects de la migration. Le portage d’un projet complexe est, en soi, un processus complexe. Ces outils peuvent vous aider dans ce parcours.

Même si vous utilisez un outil pour faciliter le portage de votre application, vous devez consulter la section Considérations relatives au portage de cet article.

Assistant de mise à niveau de .NET

L’Assistant de mise à niveau de .NET est un outil en ligne de commande qui peut être exécuté sur différents types d’applications .NET Framework. Il est conçu pour faciliter la mise à niveau des applications .NET Framework vers .NET 5. Après l’exécution de l’outil, dans la plupart des cas, l’application nécessite des efforts supplémentaires pour effectuer la migration. L’outil comprend l’installation d’analyseurs qui peuvent vous aider à effectuer la migration. Cet outil fonctionne sur les types d’applications .NET Framework suivants :

  • Windows Forms
  • WPF
  • ASP.NET MVC
  • Console
  • bibliothèques de classes ;

Cet outil utilise les autres outils répertoriés dans cet article et guide le processus de migration. Pour plus d’informations sur l’outil, consultez Vue d’ensemble de l’Assistant Mise à niveau .NET.

try-convert

L’outil try-convert est un outil global .NET qui peut convertir un projet ou une solution entière vers le SDK .NET, y compris le déplacement d’applications de bureau vers .NET 5. Toutefois, cet outil n’est pas recommandé si le processus de génération de votre projet est complexe, notamment s’il comporte des tâches personnalisées, des cibles ou des importations.

Pour plus d’informations, consultez le référentiel try-convert GitHub.

Analyseur de portabilité .NET

L’analyseur de portabilité .NET est un outil qui analyse les assemblys et fournit un rapport détaillé sur les API .NET manquantes pour que les applications ou bibliothèques soient portables sur vos plateformes .NET ciblées spécifiées.

Pour utiliser l’analyseur de portabilité .NET dans Visual Studio, installez lextension à partir de la place de marché.

Pour plus d’informations, consultez Analyseur de portabilité .NET.

Analyseur de compatibilité de plateforme

L’analyseur de compatibilité de plateforme analyse si vous utilisez ou non une API qui lève un PlatformNotSupportedException au moment de l’exécution. Bien que ce ne soit pas courant si vous passez de .NET Framework 4.7.2 ou une version ultérieure, il est bon de vérifier. Pour plus d’informations sur les API qui lèvent des exceptions sur .NET, consultez API qui lèvent toujours des exceptions sur .NET Core.

Pour plus d’informations, consultez Analyseur de compatibilité de plateforme.

Considérations à prendre en compte lors du portage

Lorsque vous transférez votre application vers .NET, tenez compte des suggestions suivantes dans l’ordre.

✔️ ENVISAGEZ d’utiliser l’Assistant Mise à niveau .NET pour migrer vos projets. Bien que cet outil soit en préversion, il automatise la plupart des étapes manuelles détaillées dans cet article et vous offre un excellent point de départ pour poursuivre votre parcours de migration.

✔️ ENVISAGEZ d’examiner vos dépendances en premier. Vos dépendances doivent cibler .NET 5, .NET Standard ou .NET Core.

✔️ EFFECTUEZ la migration à partir d’un fichier packages.config NuGet vers les paramètres PackageReference du fichier projet. Utilisez Visual Studio pour convertir le fichier package.config.

✔️ ENVISAGEZ une mise à niveau vers le dernier format de fichier projet, même si vous ne pouvez pas encore porter votre application. Les projets .NET Framework utilisent un format de projet obsolète. Même si le dernier format de projet, appelé projets de style SDK, a été créé pour .NET Core et au-delà, ils fonctionnent avec .NET Framework. Le fait d’avoir votre fichier projet dans le dernier format vous donne une bonne base pour le portage de votre application à l’avenir.

✔️ RECIBLEZ votre projet .NET Framework vers au moins .NET Framework 4.7.2. Cela garantit la disponibilité des dernières solutions API pour les cas où .NET Standard ne prend pas en charge les API existantes.

✔️ ENVISAGEZ de cibler .NET 5 au lieu de .NET Core 3.1. Bien que .NET Core 3.1 soit pris en charge à long terme (LTS), .NET 5 est le dernier et .NET 6 sera LTS lorsqu’il sera publié.

✔️ DO ciblez .NET 5 pour les projets Windows Forms et WPF. .NET 5 contient de nombreuses améliorations pour les applications de bureau.

✔️ ENVISAGEZ de cibler .NET Standard 2.0 si vous migrez une bibliothèque qui peut également être utilisée avec des projets .NET Framework. Vous pouvez également cibler votre bibliothèque à plusieurs niveaux, en ciblant à la fois .NET Framework et .NET Standard.

✔️ AJOUTEZ une référence au package NuGet Microsoft.Windows.Compatibility si, après la migration, vous obtenez des erreurs d’API manquantes. Une grande partie de la surface de l’API .NET Framework est disponible pour .NET via le package NuGet.

Voir aussi