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

2025-06-03

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 migration 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 migrer 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 migration 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 appeler des bibliothèques natives sur des plateformes prises en charge par .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 Les frameworks cibles dans les projets de type SDK.

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.
Accès à distance

La liaison à distance est utilisée pour communiquer entre des domaines d'application, mais elle n'est plus prise en charge. Pour simplifier la communication entre les processus, envisagez de mettre en place des mécanismes de communication interprocessus (IPC) à la place du remoting (par exemple, la classe System.IO.Pipes ou 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).

Étant donné que la communication à distance n’est pas prise en charge, les appels vers BeginInvoke() et EndInvoke() sur les objets délégués lèveront 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é

De la même manière que le CAS, la technique de sandboxing via 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 :

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 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 migration. 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.

L'assistant de 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 davantage d’efforts pour terminer la migration. L’outil inclut 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 (Windows Presentation Foundation)
ASP.NET MVC
Consoler
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 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 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 la plateforme analyse si vous utilisez ou non une API qui lève une PlatformNotSupportedException fois l’exécution effectuée. 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 l’Assistant Mise à niveau .NET pour migrer vos projets. Même si cet outil est en préversion, 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 migration.

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

✔️ Effectuez une migration à partir d’un fichier packages.config NuGet vers les paramètres PackageReference du fichier de 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.

✔️ Veillez à cibler votre projet .NET Framework sur la version 4.7.2 de .NET Framework au minimum. 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 6+ pour les projets Windows Forms et WPF . .NET 6 et versions ultérieures contiennent 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 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.