Partager via

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

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

Les projets dans lesquels le modèle d’application est disponible dans .NET, tels que 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 passer à ASP.NET Core à partir 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). Windows Forms et WPF sont disponibles dans .NET, mais ils restent des technologies Windows uniquement.

Tenez compte des dépendances suivantes avant de mettre à niveau une application Windows Forms ou WPF :

  • Les fichiers projet pour .NET utilisent un format différent de .NET Framework.
  • Votre projet peut utiliser une API qui n’est pas disponible dans .NET.
  • Les contrôles et bibliothèques tiers n’ont peut-être pas été portés vers .NET et restent uniquement disponibles pour .NET Framework.
  • 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 sur .NET Framework.

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

API spécifiques à Windows

Les applications peuvent toujours utiliser P/Invoke pour les bibliothèques natives sur des plateformes compatibles avec .NET. Cette technologie n’est pas limitée à Windows. Toutefois, si la bibliothèque que vous référencez est spécifique à Windows, telle qu’une user32.dll ou unekernel32.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 générique suffisant pour s’exécuter sur toutes les plateformes.

Lorsque vous transférez une application de .NET Framework vers .NET, votre application a probablement utilisé une bibliothèque fournie par .NET Framework. De nombreuses API disponibles dans .NET Framework n’ont pas été transférées vers .NET, car elles s’appuyaient sur une technologie spécifique à Windows, comme 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é .NET Framework

Le mode de compatibilité .NET Framework a été introduit dans .NET Standard 2.0. Le mode de compatibilité permet aux projets .NET Standard et .NET de référencer les bibliothèques .NET Framework comme s’ils étaient compilés pour le framework cible du projet. Toutefois, certaines implémentations .NET peuvent prendre en charge un segment plus important de .NET Framework que d’autres. Par exemple, .NET Core 3.0 étend le mode de compatibilité .NET Framework aux Windows Forms et WPF. Le référencement des bibliothèques .NET Framework ne fonctionne pas pour tous les projets, par exemple si la bibliothèque utilise des API WPF, mais elle débloque de nombreux scénarios de portage. Pour plus d’informations, consultez l’article Analyser vos dépendances pour transférer le code de .NET Framework vers .NET.

Le référencement des bibliothèques .NET Framework ne fonctionne pas dans tous les cas, car il dépend des API .NET Framework utilisées et si ces API sont prises en charge par le framework cible du projet. En outre, certaines API .NET Framework fonctionnent uniquement sur Windows. Le mode de compatibilité .NET Framework débloque de nombreux scénarios de portage, mais vous devez tester vos projets pour vous assurer qu’ils fonctionnent également au moment de l’exécution. Pour plus d’informations, consultez l’article Analyser vos dépendances pour transférer le code de .NET Framework vers.

Modifications du framework cible dans les projets de style SDK

Comme mentionné précédemment, les fichiers projet pour .NET utilisent un format différent de .NET Framework, appelé format de projet de style SDK. Même si vous ne passez pas de .NET Framework à .NET, vous devez toujours mettre à niveau le fichier projet au dernier format. La façon de spécifier un framework cible est différente dans les projets de style SDK. Dans .NET Framework, la <TargetFrameworkVersion> propriété est utilisée avec un moniker qui spécifie la version de .NET Framework. Par exemple, .NET Framework 4.7.2 ressemble à l’extrait de code suivant :

<PropertyGroup>
  <TargetFrameworkVersion>v4.7.2</TargetFrameworkVersion>
</PropertyGroup>

Un projet de style SDK utilise une propriété différente pour identifier l’infrastructure cible, la <TargetFramework> propriété. Lorsque vous ciblez .NET Framework, le moniker commence par net et se termine par la version de .NET Framework sans période. Par exemple, le moniker pour cibler .NET Framework 4.7.2 est net472:

<PropertyGroup>
  <TargetFramework>net472</TargetFramework>
</PropertyGroup>

Pour obtenir la liste de tous les monikers cibles, consultez Frameworks cibles dans les projets de style SDK.

Technologies indisponibles

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

  • Domaines d’application

    La création d’autres domaines d’application 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, considérez les mécanismes de communication interprocessus (IPC) comme une alternative à la communication à distance, telles que la classe System.IO.Pipes ou la classe MemoryMappedFile. Pour des scénarios plus complexes, envisagez des infrastructures telles que StreamJsonRpc ou ASP.NET Core (à l’aide de gRPC ou de services d’API web RESTful).

    Comme la communication à distance n’est pas prise en charge, les appels vers BeginInvoke() et EndInvoke() sur les objets délégués génèrent des exceptions PlatformNotSupportedException.

  • Sécurité de l’accès au 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 La transparence de la sécurité et n’est pas prise en charge dans .NET. Utilisez plutôt des 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é

    Comme le CAS, la technique de bac à sable basée sur la transparence de sécurité n'est plus recommandée pour les applications .NET Framework et elle n'est pas prise en charge dans .NET. Utilisez plutôt des 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. Pour obtenir une alternative, consultez CoreWF.

Pour plus d’informations sur ces technologies non prises en charge, consultez les technologies .NET Framework non disponibles sur .NET 6+.

Multiplateforme

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

  • Libraries
  • Outils basés sur la console
  • Automation
  • 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 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 multiplateforme sans changer beaucoup. Lorsque vous effectuez un portage vers .NET, vous pouvez prendre en compte cette question et tester votre application sur d’autres plateformes.

L’avenir de .NET Standard

.NET Standard est une spécification formelle des API .NET disponibles sur plusieurs implémentations .NET. La motivation de .NET Standard était d’établir une plus grande uniformité dans l’écosystème .NET. À compter de .NET 5, une approche différente de l’établissement de l’uniformité a été adoptée, et cette nouvelle approche élimine la nécessité de .NET Standard dans de nombreux scénarios. Pour plus d’informations, consultez .NET 5+ et .NET Standard.

.NET Standard 2.0 était la dernière version pour 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 mise à niveau. Le portage d’un projet complexe est, en soi, un processus complexe. Les outils peuvent vous aider dans ce parcours.

Même si vous utilisez un outil pour faciliter le portage de votre application, vous devez passer en revue les considérations lors du portage de la section dans cet article.

Assistant de modernisation des applications pour GitHub Copilot

La modernisation des applications GitHub Copilot est un assistant conversation GitHub Copilot qui vous aide à planifier et mettre à niveau des projets vers des versions plus récentes de .NET, migrer vers Azure, mettre à jour les dépendances et appliquer des correctifs de code. La migration Azure est optimisée par l’évaluation de l’application et du code pour .NET

Cet assistant de chat prend en charge les chemins de mise à niveau suivants :

  • Mettez à niveau les projets d’anciennes versions de .NET vers la dernière version.
  • Mettez à niveau les projets de .NET Framework vers la dernière version de .NET.
  • Moderniser votre base de code avec de nouvelles fonctionnalités.
  • Migrez des composants et des services vers Azure.

Il fonctionne également sur différents types de projets, tels que :

  • ASP.NET et technologies connexes telles que MVC, Razor Pages, API web
  • Blazor
  • Azure Functions
  • Windows Presentation Foundation
  • Windows Forms
  • bibliothèques de classes ;
  • Applications de console

Quand les utiliser :

Utilisez GitHub Copilot pour la modernisation des applications lorsque vous souhaitez une expérience de bout en bout basée sur l'IA pour mettre à niveau des projets et des dépendances du .NET Framework vers le .NET moderne, couvrant l’évaluation, la planification, la remédiation et les conseils pour la migration d’applications vers Azure.

Évaluation de l’application et du code pour .NET

L’application et l’évaluation du code Azure Migrate pour .NET fournissent du code et de l’analyse des applications, ainsi que des recommandations pour la planification des déploiements cloud. Il vous aide à exécuter en toute confiance des solutions critiques dans le cloud en offrant une évaluation axée sur les développeurs de votre code source. L’outil fournit également des recommandations et des exemples pour optimiser le code et les configurations pour Azure, en suivant les meilleures pratiques du secteur.

Cet outil est également utilisé par la modernisation de l’application GitHub Copilot pour l’expérience .NET.

Quand les utiliser :

Utilisez l’application Azure Migrate et l’évaluation du code pour l’ensemble d’outils .NET pour une évaluation et des recommandations relatives à la migration d’une base de code existante vers Azure. L’application et l’évaluation du code Azure Migrate sont essentiellement un sous-ensemble de la modernisation de l’application GitHub Copilot pour l’expérience .NET.

Assistant Mise à niveau .NET

L’Assistant Mise à niveau .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. Après avoir exécuté l’outil, dans la plupart des cas, l’application nécessite plus d’efforts pour terminer la mise à niveau. L’outil inclut l’installation d’analyseurs qui peuvent vous aider à effectuer la mise à niveau. Cet outil fonctionne sur les types d’applications .NET Framework suivants :

  • Windows Forms
  • WPF (Windows Presentation Foundation)
  • ASP.NET MVC
  • Console
  • bibliothèques de classes ;

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

Quand les utiliser :

Utilisez une solution basée sur l'IA lorsque la modernisation des applications avec GitHub Copilot n'est pas disponible.

try-convert

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

Pour plus d’informations, consultez le try-convert dépôt GitHub.

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 la recherche de l’une de ces API soit peu probable si vous passez de .NET Framework 4.7.2 ou version ultérieure, il est préférable de vérifier. Pour plus d’informations sur les API qui lèvent des exceptions sur .NET, consultez les API qui lèvent toujours des exceptions sur .NET Core.

Pour plus d’informations, consultez l’analyseur de compatibilité de la plateforme.

Considérations relatives au portage

Lors du portage de votre application vers .NET, tenez compte des suggestions suivantes dans l’ordre :

✔️ ENVISAGEZ d’utiliser la modernisation de l’application GitHub Copilot pour mettre à niveau vos projets. GitHub Copilot est puissant pour identifier et résoudre les incompatibilités lors du portage. Il automatise la plupart des étapes manuelles détaillées dans cet article et vous donne un excellent point de départ pour poursuivre votre chemin de mise à niveau.

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

✔️ Effectuez une mise à niveau à partir d'un fichier NuGet packages.config vers les paramètres dans le fichier projet. Utilisez Visual Studio pour convertir le package.config fichier.

✔️ ENVISAGEz la 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à, le format fonctionne également avec .NET Framework. Le fait d’avoir votre fichier projet au format le plus récent vous donne une bonne base pour le portage de votre application à l’avenir.

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

✔️ ENVISAGEZ de cibler .NET 8, qui est une version de support à long terme (LTS).

✔️ Ciblez .NET 8+ pour les projets Windows Forms et WPF . .NET 8 et versions ultérieures contiennent de nombreuses améliorations pour les applications de bureau.

✔️ ENVISAGEZ de cibler .NET Standard 2.0 si vous mettez à niveau une bibliothèque qui peut également être utilisée avec des projets .NET Framework. Vous pouvez également multitargetr votre bibliothèque, 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 d’API .NET Framework est disponible pour .NET via le package NuGet.

Voir aussi

  • Last updated on