Parlez-nous de l’expérience de téléchargement de PDF.

Documentation sur la migration vers

.NET
Découvrez comment migrer des applications de .NET Framework vers .NET.

Migrer à partir de .NET Framework

ｅ VUE D’ENSEMBLE

Déplacer du .NET Framework à .NET Core

Assistant Mise à niveau

ｉ RÉFÉRENCE

Informations de contrôle de version

Vue d’ensemble du portage de
.NET Framework vers .NET
Article • 24/07/2024

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 :

Migrer des applications WPF .NET Framework vers .NET

Migrer des applications Windows Forms .NET Framework vers .NET
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
Vue d’ensemble de l’Assistant Mise à niveau de .NET
migration de ASP.NET vers ASP.NET Core
Migrer des applications WPF .NET Framework vers .NET
Migrer des applications Windows Forms .NET Framework vers .NET
.NET 5 et .NET Framework pour les applications serveur

Commentaires
Cette page a-t-elle été utile ?  Yes  No

Indiquer des commentaires sur le produit

SDK .NET, MSBuild et contrôle de
version Visual Studio
Article • 30/01/2025

Le contrôle de version du Kit de développement logiciel (SDK) .NET et la façon dont il se

rapporte à Visual Studio et MSBuild peut prêter à confusion. Versions MSBuild avec
Visual Studio également incluses dans le SDK .NET. Le SDK a une version minimale de
MSBuild et de Visual Studio avec laquelle il fonctionne, et il ne se charge pas dans une
version de Visual Studio antérieure à cette version minimale.

Gestion de version
La première partie de la version du SDK .NET correspond à la version .NET qu’il inclut,
sur laquelle il fonctionne et qu’il cible par défaut. La bande de fonctionnalités
commence à 1 et augmente pour chaque version mineure de Visual Studio tous les
trimestres. La version de patch incrémente avec les mises à jour de maintenance de
chaque mois.

Par exemple, la version 7.0.203, fournie avec .NET 7, est la deuxième version mineure de
Visual Studio depuis la version 7.0.100, et le troisième patch depuis la version 7.0.200.

Une installation de Visual Studio comprend une copie unique du SDK .NET. Si vous
mettez à jour votre instance de Visual Studio, le SDK .NET installé par Visual Studio est
également mis à jour, y compris les bandes de fonctionnalités et les bandes majeures du
SDK .NET. Si vous souhaitez utiliser un SDK .NET différent de celui installé par Visual
Studio, vous pouvez l'installer à partir de la page de téléchargement .NET , et la mise à
jour de Visual Studio ne touchera pas cette version. Vous êtes responsable de la mise à
jour de cette copie du SDK .NET à partir de ce moment-là.

７ Notes

Le SDK .NET permet de cibler les versions inférieures de .NET, c'est pourquoi nous vous
recommandons de toujours mettre à jour votre SDK .NET en même temps que votre
version de Visual Studio.

Cycle de vie
La période de prise en charge du SDK correspond généralement à celle de la version de
Visual Studio qui l’inclut.
Développer pour voir les versions .NET sans prise en charge

ﾉ Agrandir le tableau

Version du SDK Version MSBuild/Visual Studio Date d’expédition Cycle de vie

2.1.5xx 15,9 Novembre 2018 Août 2021

2.1.8xx 16.2 (sans VS) Juillet 2019 Août 2021

3.1.1xx 16.4 Décembre 2019 Octobre 2021

3.1.4xx 16.7 Août 2020 Décembre 2022

5.0.1xx 16.8 Novembre 2020 Mars 2021

5.0.2xx 16,9 Mars 2021 Mai 2022

5.0.3xx 16,10 Mai 2021 Août 2021

5.0.4xx 16.11 Août 2021 Mai 2022

6.0.1xx 17,0 Novembre 2021 24 novembre

6.0.2xx 17.1 Février 2022 Mai 2022

6.0.3xx 17.23 Mai 2022 Octobre 2023

6.0.4xx 17.3 Août 2022 24 novembre

7.0.1xx 17.4 Novembre 2022 Mai 24

7.0.2xx 17.53 Février 2023 Mai 2023

7.0.3xx 17.6 Mai 2023 Mai 24

7.0.4xx 17,7 Août 2023 Mai 24

Versions .NET prises en charge

ﾉ Agrandir le tableau

Version du SDK Version MSBuild/Visual Studio Date d’expédition Cycle de vie

8.0.1xx 17.8 Novembre 2023 Novembre 251

8.0.2xx 17.9 Février 2024 Mai 24

 Version du SDK Version MSBuild/Visual Studio Date d’expédition Cycle de vie

8.0.3xx 17.10 Mai 24 À définir

8.0.4xx 17.11 Août 24 Novembre 252

9.0.1xx 17.12 24 novembre Mai '26

9.0.2xx 17.13 25 février Mai '26

9.0.3xx 17.14 Mai '25 Mai '26

７ Notes

1
. Les bandes de fonctionnalités du SDK .1xx sont prises en charge tout au long du
cycle de vie des principales versions de .NET. Pendant la période de support
étendue, la prise en charge est limitée aux correctifs de sécurité et aux correctifs de
sécurité à priorité élevée minimum pour Linux uniquement. Pour découvrir plus
d’informations sur le raisonnement de ce support étendu, consultez Prise en
charge de la génération source .

2Les bandes de fonctionnalités du SDK .NET .4xx sont prises en charge pendant la
durée de vie du runtime correspondant en tant qu’installations autonomes.

Cycle de vie de Visual Studio 2019

Cycle de vie de Visual Studio 2022

Ciblage et règles de support

Une stratégie suivante détermine quelles versions de MSBuild et Visual Studio une
version donnée du Kit de développement logiciel (SDK) .NET s’exécutera :

Chaque nouveau TargetFramework nécessite une nouvelle version de Visual Studio

ou une nouvelle version de dotnet .
La première version de Visual Studio qui prend en charge un nouveau
TargetFramework devient un plancher pour les bandes de fonctionnalités de ce Kit
de développement logiciel (SDK) pour la surface de l’API Roslyn, les cibles MSBuild,
les générateurs de source, les analyseurs, etc.
La première version d’un nouveau SDK .NET qui prend en charge un nouveau
TargetFramework peut toujours être utilisée avec la version précédente de Visual
Studio pour permettre un trimestre pour la migration des outils et de
l’infrastructure (actions et pipelines, par exemple).
 ﾉ Agrandir le tableau

Kit Version Version minimale TargetFramework max TargetFramework max

SDK Visual de Visual Studio dans dans dotnet
Studio version minimale de
fournie Visual Studio
avec le SDK

8.0.100 17.8 17,7 Net7.0 Net8.0

8.0.200 17.9 17.8 Net8.0 Net8.0

8.0.300 17.10 17.8 Net8.0 Net8.0

8.0.400 17.11 17.8 Net8.0 Net8.0

9.0.100 17.12 17.11 Net8.0 Net9.0

9.0.200 17.13 17.12 Net9.0 Net9.0

9.0.300 17.14 17.12 Net9.0 Net9.0

７ Notes

Le tableau montre comment ces règles de gestion de version sont appliquées, à

partir du KIT SDK .NET 7.0.100 et du KIT SDK .NET 6.0.300. Il montre également
comment la stratégie aurait été appliquée aux versions précédemment fournies du
SDK .NET si elle avait été en place. Toutefois, les conditions requises pour les
versions précédentes du kit de développement logiciel (SDK) ne changent pas, à
savoir que la version minimale requise de Visual Studio pour le kit de
développement logiciel (SDK) .NET 6.0.100 ou 6.0.200 reste la version 16.10.

Le ciblage de net8.0 est officiellement pris en charge dans Visual Studio 17.8+
uniquement.

Le ciblage net9.0 est officiellement pris en charge dans Visual Studio 17.12+
uniquement.

Afin de garantir la cohérence des outils, vous devez utiliser dotnet build plutôt que
msbuild pour générer votre application lorsque cela est possible.

Préversions
Les versions principales du SDK .NET sont généralement publiées quelques jours après
une préversion de Visual Studio. Bien qu’il existe d’autres combinaisons qui
fonctionnent, seule la dernière préversion publiée est testée et officiellement prise en
charge. Le tableau suivant montre avec quelle version de Visual Studio chaque
préversion de .NET a été testée avant d’être publiée.

ﾉ Agrandir le tableau

Préversion du SDK Version Visual Studio

9.0.100 RC 1 17.12 Préversion 2

9.0.100 RC 2 17.12 Préversion 3

9.0.100 GA 17.12 GA

10.0.100 Preview 1 17.14 Préversion 1

Référence
Vue d’ensemble de la façon dont .NET est versionné
Stratégie de support officielle .NET et .NET Core
Microsoft .NET et .NET Core
Téléchargements .NET (Windows, Linux et macOS)
Cycle de vie et maintenance des produits Visual Studio 2019
.NET et .NET Framework pour les
applications serveur
Article • 07/06/2024

Deux implémentations de .NET sont prises en charge pour la création d’applications

côté serveur : .NET et .NET Framework. La dernière version de .NET (actuellement
.NET 8) est la version préférée de .NET à utiliser pour le développement serveur. Les
raisons de continuer à utiliser .NET Framework sont spécifiques et limitées.

ﾉ Agrandir le tableau

Implémentation Versions incluses

.NET .NET Core 1.0 - 3.1

.NET 5 et versions ultérieures de .NET

.NET Framework .NET Framework 1.0 - 4.8

Choisir .NET
.NET présente les avantages suivants pour les applications serveur :

Fonctionne sur plusieurs plateformes.

.NET permet à votre application web ou de service de s’exécuter sur plusieurs

plateformes, par exemple Windows, Linux et macOS. Vous pouvez également
utiliser l’un de ces systèmes d’exploitation comme station de travail de
développement. Utilisez l’environnement de développement intégré (IDE) Visual
Studio sur Windows ou utilisez Visual Studio Code sur macOS, Linux ou Windows.
Visual Studio Code prend en charge IntelliSense et le débogage. La plupart des
éditeurs tiers, tels que Sublime, Emacs et VI, fonctionnent avec .NET. Ces éditeurs
tiers obtiennent l’éditeur IntelliSense en utilisant Omnisharp . Vous pouvez
également ignorer l’éditeur de code et utiliser directement l’interface CLI .NET.

Vous permet de cibler des microservices.

Une architecture en microservices permet une combinaison de technologies au-

delà des limites d’un service. Cette combinaison de technologies favorise
l’adoption progressive de .NET pour les nouveaux microservices qui utilisent
d’autres microservices ou services. Par exemple, vous pouvez combiner des
microservices ou services développés avec .NET Framework, Java, Ruby ou d’autres
technologies monolithiques.

Il existe de nombreuses plateformes d’infrastructure. Azure Service Fabric est

conçu pour les systèmes de microservice volumineux et complexes. Azure App
Service est un bon choix pour les microservices sans état. Les alternatives aux
microservices basées sur Docker s’intègrent à toute approche des microservices,
comme expliqué dans la section suivante (Prend en charge les conteneurs Docker).
Toutes ces plateformes prennent en charge .NET et s’avèrent idéales pour
l’hébergement de vos microservices.

Pour plus d’informations sur l’architecture en microservices, consultez

Microservices .NET. : architecture des applications .NET conteneurisées.

Prend en charge les conteneurs Docker.

Les conteneurs sont couramment utilisés avec une architecture en microservices.

Les conteneurs peuvent également servir à mettre en conteneur des applications
ou services web qui suivent un modèle d’architecture. Bien que le .NET Framework
peut être utilisé pour les conteneurs Windows, la modularité et la légèreté de .NET
Core en font un meilleur choix pour les conteneurs. Quand vous créez et déployez
un conteneur, la taille de son image est beaucoup plus petite avec .NET qu’avec
.NET Framework. Grâce à sa nature multiplateforme, vous pouvez déployer des
applications serveur sur des conteneurs Docker Linux.

Vous pouvez héberger les conteneurs Docker dans votre propre infrastructure
Windows ou Linux, ou dans un service cloud comme Azure Kubernetes Service .
Azure Kubernetes Service permet de gérer, d’orchestrer et de mettre à l’échelle des
applications sur conteneur dans le cloud.

Est hautement performant et évolutif.

Quand votre système a besoin de performances et d’une scalabilité optimales,

.NET et ASP.NET Core sont vos meilleures options. Le runtime serveur hautes
performances pour Windows Server et Linux fait d’ASP.NET Core un framework
web particulièrement puissant, d’après les bancs d’essai TechEmpower .

Niveau de performance et scalabilité sont particulièrement pertinents pour les

architectures en microservices, où des centaines de microservices peuvent être en
cours d’exécution. Avec ASP.NET Core, les systèmes s’exécutent avec un nombre
beaucoup plus faible de serveurs ou de machines virtuelles, ce qui permet
d’économiser des coûts sur l’infrastructure et l’hébergement.

Prend en charge les versions .NET côte à côte par application.

 L’implémentation .NET prend en charge les installations côte à côte de différentes
versions du runtime .NET sur le même ordinateur. Cette fonctionnalité permet
plusieurs services sur le même serveur, chacun sur sa propre version de .NET. De
plus, les risques et les coûts liés aux opérations informatiques et aux mises à
niveau des applications s’en trouvent réduits.

L’installation côte à côte n’est pas possible avec .NET Framework. Il s’agit d’un
composant Windows et une seule version peut exister sur un ordinateur à la fois :
chaque version de .NET Framework remplace la version précédente. Si vous
installez une nouvelle application qui cible une version ultérieure de
.NET Framework, vous risquez d’arrêter les applications existantes qui s’exécutent
sur l’ordinateur, car la version précédente a été remplacée.

Est plus sécurisé.

Quand choisir .NET Framework

Comme mentionné précédemment, l’implémentation .NET offre des avantages
significatifs pour les nouvelles applications et les modèles d’application. Toutefois, dans
certains scénarios spécifiques, vous devrez peut-être utiliser .NET Framework pour vos
applications serveur, et .NET Framework continuera d’être pris en charge. Utilisez .NET
Framework pour votre application serveur quand :

Votre application utilise actuellement .NET Framework.

Dans la plupart des cas, vous n’avez pas besoin de migrer vos applications
existantes vers .NET. Nous vous recommandons plutôt d’utiliser .NET quand vous
étendez une application existante, par exemple quand vous écrivez un nouveau
service web dans ASP.NET Core.

Votre application utilise des packages NuGet ou des bibliothèques tiers non
disponibles pour .NET.

.NET standard permet de partager du code sur toutes les implémentations de .NET,
y compris .NET 6+. Avec .NET Standard 2.0, un mode de compatibilité permet aux
projets .NET Standard et .NET de référencer des bibliothèques .NET Framework.
Pour plus d’informations, consultez Prise en charge des bibliothèques
.NET Framework.

Vous devez utiliser .NET Framework seulement quand les bibliothèques ou les
packages NuGet utilisent des technologies qui ne sont pas disponibles dans
.NET Standard ou .NET.
 Votre application utilise des technologies .NET Framework non disponibles pour
.NET

Certaines technologies .NET Framework ne sont pas disponibles dans .NET. La liste
suivante présente les technologies les plus courantes non disponibles dans .NET :
Applications ASP.NET Web Forms : ASP.NET Web Forms est disponible
uniquement dans .NET Framework. ASP.NET Core ne peut pas être utilisé pour
ASP.NET Web Forms.
Applications pages Web ASP.NET : le framework pages Web ASP.NET n’est pas
inclus dans ASP.NET Core.
Services liés aux workflows : Windows Workflow Foundation (WF), les services
de workflow (WCF + WF dans un seul service) et WCF Data Services
(anciennement « ADO.NET Data Services ») sont disponibles uniquement dans
.NET Framework.
Prise en charge des langages : Visual Basic et F# sont pris en charge dans .NET,
mais pas pour tous les types de projet. Pour obtenir la liste des modèles de projet
pris en charge, consultez Options de modèle pour dotnet new.

Pour plus d’informations, consultez Technologies .NET Framework non disponibles

dans .NET.

Votre application utilise une plateforme qui ne prend pas en charge .NET

Certaines plateformes Microsoft ou tierces ne prennent pas en charge .NET.

Certains services Azure fournissent un kit SDK qui n’est pas encore consommable
sur .NET. Dans ce cas, vous pouvez utiliser l’API REST équivalente au lieu du SDK
client.

Voir aussi
Choisir entre ASP.NET et ASP.NET Core
ASP.NET Core ciblant .NET Framework
Frameworks cibles
Présentation de .NET
Portage de .NET Framework vers .NET 5
Introduction à .NET et à Docker
Implémentations de .NET
Microservices .NET. Architecture pour les applications .NET en conteneur
６ Collaborer avec nous sur Commentaires sur .NET
GitHub .NET est un projet open source.
La source de ce contenu se Sélectionnez un lien pour fournir des
trouve sur GitHub, où vous commentaires :
pouvez également créer et
examiner les problèmes et les  Ouvrir un problème de
demandes de tirage. Pour plus documentation
d’informations, consultez notre
guide du contributeur.  Indiquer des commentaires sur
le produit
Qu’est-ce que l’Assistant Mise à niveau
.NET ?
Article • 31/10/2024

L’Assistant Mise à niveau .NET permet de mettre à niveau des projets vers des versions
plus récentes de .NET et analyse votre code pour repérer et corriger les incompatibilités
potentielles. L’un des principaux éléments de l’outil est d’aider à migrer un projet de
.NET Framework, .NET Core ou .NET vers la dernière version de .NET. Vous utilisez
l’extension ou l’outil pour mettre à niveau des projets .NET entiers, ou un aspect du
projet, par exemple la migration d’un fichier de configuration d’un type plus ancien vers
un type plus récent.

L’Assistant Mise à niveau .NET est distribué en tant qu’extension Visual Studio ou outil
d’interface de ligne de commande (CLI).

Analyser et mettre à niveau

L’Assistant Mise à niveau .NET inclut un moteur d’analyse qui analyse vos projets et leurs
dépendances. Une fois l’analyse terminée, un rapport est généré avec des informations
détaillées sur l’exécution d’une mise à niveau. Vous pouvez utiliser ces informations pour
mettre à niveau l’ensemble du projet ou des parties spécifiques du projet.

Types de projet pris en charge

L’Assistant Mise à niveau .NET prend en charge la mise à niveau de projets codés en C#
ou Visual Basic. Les types de projets suivants sont pris en charge :

ASP.NET
Azure Functions
Windows Presentation Foundation
Windows Forms
bibliothèques de classes ;
Applications de console
Xamarin Forms
.NET MAUI
UWP .NET Native

Certains produits fournissent des conseils sur l’utilisation de l’Assistant Mise à niveau
.NET.
 ASP.NET
Windows Presentation Foundation
Windows Forms
Plateforme Windows universelle
Windows Communication Foundation

Chemins de mise à jour

Les chemins de mise à niveau suivants sont pris en charge :

.NET Framework vers .NET

.NET Core vers .NET
Azure Functions v1-v3 vers v4 isolé (ciblant net6.0+)
UWP vers WinUI 3
Version précédente de .NET à la dernière version de .NET
Xamarin Forms vers .NET MAUI
Les transformations de fichiers XAML prennent uniquement en charge la mise à
niveau des espaces de noms. Pour des transformations plus complètes, utilisez
Visual Studio 2022 version 17.6 ou ultérieure.

Détails et options de mise à niveau

Quand une mise à niveau est démarrée, un Assistant vous guide tout au long de la
configuration de certaines des options avant le lancement de la mise à niveau. En
fonction du type de projet que vous mettez à niveau, l’Assistant présente différentes
options. Pour obtenir un exemple de mise à niveau d’un projet, consultez Mettre à
niveau des projets avec l’Assistant Mise à niveau .NET.

Comment effectuer la mise à niveau

En fonction du type de projet que vous mettez à niveau, vous pouvez peut-être modifier
la façon dont la mise à niveau est effectuée. Le type de projet affecte les options
disponibles, et un ou plusieurs des éléments suivants peuvent être manquants :

Mise à niveau de projet sur place

Cette option met à niveau votre projet sans effectuer de copie.

Mise à niveau de projet côte à côte

Copie votre projet et met à niveau la copie, en laissant votre projet d’origine seul.
 Incrémentielle côte à côte

Il s’agit d’un bon choix pour les applications web complexes. La mise à niveau de
ASP.NET vers ASP.NET Core nécessite beaucoup de travail et parfois une
refactorisation manuelle. Ce mode place un projet .NET en regard du projet .NET
Framework existant. Les points de terminaison sont routés via le projet .NET, tandis
que tous les autres appels sont envoyés à l’application .NET Framework.

Ce mode vous permet de mettre à niveau lentement votre ASP.NET ou votre

application de bibliothèque.

Résultats de la mise à niveau

Une fois la mise à niveau terminée, un écran d’état s’affiche qui affiche tous les artefacts
associés à la mise à niveau. Chaque artefact de mise à niveau peut être développé pour
lire plus d’informations sur l’état. La liste suivante décrit les icônes d’états :

Coche verte non remplie : l’outil n’a rien trouvé concernant l’artefact à mettre à
niveau.
Coche verte remplie : l’artefact a été mis à niveau et s’est terminé avec succès.
Signe d’avertissement jaune : l’artefact a été mis à niveau, mais vous devez
prendre en compte des informations importantes.
Red X : échec de la mise à niveau de l’artefact.

En outre, les actions effectuées pendant la mise à niveau sont enregistrées dans la
fenêtre Sortie sous la source de l’Assistant Mise à niveau, comme illustré dans l’image
suivante :

Après la mise à niveau de votre projet, testez-le soigneusement !

Contenu connexe
Qu’est-ce que l’analyse du code avec l’Assistant Mise à niveau .NET ?
Installer l’Assistant Mise à niveau .NET
Analyser des projets avec l’Assistant Mise à niveau .NET
Mettre à niveau des projets avec l’Assistant Mise à niveau .NET
Installer l’Assistant Mise à niveau .NET
Article • 31/10/2024

Cet article explique comment installer l’Assistant Mise à niveau .NET à l’aide de
l’extension Visual Studio ou de l’outil CLI (interface de ligne de commande).

Prérequis
Système d'exploitation Windows
Visual Studio 2022 version 17.1 ou ultérieure .
Kit de développement logiciel (SDK) .NET 8 ou version ultérieure .

Méthodes
L’Assistant Mise à niveau .NET peut être installé en tant qu’extension Visual Studio ou en
tant qu’outil global .NET.

L’extension Visual Studio s’exécute dans Visual Studio, sur la solution ou le projet que
vous avez ouvert. L’outil global .NET est une application console interactive qui
s’exécute sur une solution ou un fichier projet situé ou sous le répertoire actif.

Si vous souhaitez que l’expérience simplifiée d’ouverture d’un projet dans Visual Studio
et sa mise à niveau, installez l’extension.

Extension Visual Studio

Les étapes suivantes installent l’extension Visual Studio.

 Conseil

En guise d’alternative à l’utilisation de la fonctionnalité Gérer les extensions de

Visual Studio, vous pouvez télécharger et exécuter le programme d’installation des
extensions à partir de Visual Studio Marketplace

1. Ouvrez Visual Studio.

Si la fenêtre Ouvrir récent \ Prise en main s’ouvre, sélectionnez le lien Continuer

sans code .
 2. Sélectionnez le menu Extensions Gérer les extensions> pour ouvrir la fenêtre
Gestionnaire d’extensions.

3. Sélectionnez l’onglet Parcourir.

4. Tapez l’Assistant mise à niveau .NET dans la zone de recherche.

5. Sélectionnez l’élément Assistant Mise à niveau .NET, puis sélectionnez Installer.

6. Une fois l’extension téléchargée, fermez Visual Studio pour démarrer

automatiquement l’installation.

7. Sélectionnez Modifier et suivez les instructions pour installer l’extension.

Outil global .NET

Les étapes suivantes installent l’Assistant Mise à niveau .NET en tant qu’outil global .NET.
L’Assistant Mise à niveau .NET est distribué dans le package NuGet de l’Assistant mise
à niveau.
 1. Ouvrez une invite de commandes contenant la commande dans Chemin d’accès
dotnet .

2. Exécutez la commande suivante pour installer l’outil :

CLI .NET

dotnet tool install -g upgrade-assistant

） Important

L’installation de cet outil peut échouer si vous avez configuré une autre
source de flux NuGet. Utilisez le --ignore-failed-sources paramètre pour
traiter ces échecs comme des avertissements au lieu d’erreurs, en contournant
ces autres sources de flux NuGet :

CLI .NET

dotnet tool install -g --ignore-failed-sources upgrade-assistant

Validation
Les informations suivantes vous aident à déterminer que l’Assistant Mise à niveau .NET
est installé.

Visual Studio Extension

Il existe deux façons de déterminer si l’Assistant Mise à niveau .NET est installé en
tant qu’extension Visual Studio. La méthode la plus rapide consiste à cliquer avec
le bouton droit sur n’importe quel projet .NET ou .NET Framework dans la fenêtre
Explorateur de solutions et à rechercher un élément de menu Mettre à niveau.

Une autre méthode consiste à sélectionner le menu Extensions Gérer les

extensions> pour ouvrir la fenêtre Gestionnaire d’extensions. Sélectionnez ensuite
l’onglet Installé et recherchez-le dans la liste des extensions installées.

Outil global .NET

Ouvrez une invite de commandes et exécutez la upgrade-assistant commande. Si

la réponse de commande indique que la commande est inconnue, l’outil n’a pas
été installé correctement ou n’est pas dans PATH.
Résoudre les problèmes - Outil global .NET
Si vous avez configuré des sources de flux NuGet supplémentaires, l’installation peut
échouer avec une erreur indiquant que le package NuGet n’est pas disponible dans le
flux. Utilisez le --ignore-failed-sources paramètre pour traiter ces échecs comme des
avertissements au lieu d’erreurs, en contournant les autres sources de flux NuGet :

CLI .NET

dotnet tool install -g --ignore-failed-sources upgrade-assistant

Mettre à niveau des projets avec
l’Assistant Mise à niveau .NET
Article • 31/10/2024

L’objectif de cet article est de fournir les étapes de base pour mettre à niveau un projet
avec l’Assistant Mise à niveau .NET. Cela implique de lancer la mise à niveau et
d’examiner les résultats. En fonction de la complexité de votre projet, vous devrez peut-
être effectuer des mises à jour manuelles de votre code.

Certains types de projets ont des conseils spécifiques sur la mise à niveau. Pour plus
d’informations, consultez Types de projets pris en charge.

Prérequis
Pour Visual Studio, consultez Installer l’Assistant Mise à niveau .NET - Extension
Visual Studio
Pour l’outil global .NET, consultez l’Assistant Installation de l’Assistant Mise à
niveau .NET - Outil global .NET

Mettre à niveau un projet dans Visual Studio

Procédez comme suit pour mettre à niveau un projet dans Visual Studio.

1. Sauvegardez votre code.

2. Ouvrez Visual Studio.

3. Ouvrez un projet ou une solution.

4. Dans la fenêtre Explorateur de solutions, cliquez avec le bouton droit sur le

projet>Mettre à niveau.
5. Sous l’onglet Mise à niveau , sélectionnez les options de mise à niveau
appropriées.

En fonction du type de projet et de la version du framework cible, différentes

options sont présentées. L’image suivante montre deux options lors de la mise à
niveau d’un projet Windows Forms pour .NET Framework. Ces options ne
s’affichent pas lors de la mise à niveau d’un projet .NET :

Dans cet exemple, sélectionnez Mettre à niveau le projet vers une version plus
récente de .NET.
6. Sélectionnez la façon dont vous souhaitez effectuer la mise à niveau. Sélectionnez
Mise à niveau du projet sur place, puis sélectionnez Suivant.

Certains projets ne peuvent vous présenter qu’une seule option. Pour plus
d’informations sur ces options, consultez Comment effectuer la mise à niveau.

7. Sélectionnez le framework cible, par exemple .NET 8.0. Sélectionnez ensuite

Suivant.

8. Sélectionnez les composants à mettre à niveau, puis sélectionnez Mettre à niveau

la sélection.
 9. Une fois la mise à niveau terminée, une liste d’éléments traités s’affiche.

Chaque artefact traité par la mise à niveau est répertorié, ainsi que son état. Pour plus
d’informations, consultez Les résultats de la mise à niveau.

Mettre à niveau un projet à partir de l’interface

CLI
Procédez comme suit pour mettre à niveau un projet à l’aide du terminal. L’outil global
.NET est un outil interactif qui vous guide tout au long des options de mise à niveau.
Utilisez les touches Flèche haut et Bas pour modifier l’option mise en surbrillance, puis
Entrez pour exécuter l’option Sélectionner l’option. Chaque écran vous présente des
options sur la façon dont vous souhaitez configurer la mise à niveau.

1. Sauvegardez votre code.

2. Ouvrez un terminal et accédez au dossier contenant la solution ou le projet que

vous souhaitez mettre à niveau.

3. Pour démarrer l’outil, exécutez la upgrade-assistant upgrade commande.

Vous êtes invité à savoir ce que vous souhaitez mettre à niveau. Selon ce qui est
détecté, certaines options peuvent être appliquées automatiquement ou
manquantes entièrement.

4. Si plusieurs projets sont trouvés, choisissez l’un des projets, puis appuyez sur
Entrée .

Mettez à niveau les projets dans l’ordre de leur dépendance. Par exemple, l’image
précédente a montré deux projets : MatchingGame et MatchingGame.Logic .
MatchingGame dépend MatchingGame.Logic de , il doit donc MatchingGame.Logic être

mis à niveau en premier.

5. Si vous avez la possibilité de modifier le type de mise à niveau, choisissez-en un,

puis appuyez sur Entrée . Si une seule option était disponible, elle aurait été
sélectionnée automatiquement.

Pour plus d’informations sur ces options, consultez Comment effectuer la mise à
niveau.

 Conseil
 Si vous avez sauvegardé votre code, il est sûr de sélectionner La mise à
niveau du projet sur place.

6. Choisissez un framework cible, tel que .NET 8.0, puis appuyez sur Entrée .

7. L’invite finale est une confirmation, affichant toutes les options sélectionnées.
Appuyez sur Entrée pour démarrer la mise à niveau.

8. Une fois la mise à niveau terminée, un résumé s’affiche.

Contenu connexe
Qu’est-ce que l’Assistant Mise à niveau .NET ?
Qu’est-ce que l’analyse du code avec l’Assistant Mise à niveau .NET ?
Analyser des projets avec l’Assistant Mise à niveau .NET
Qu’est-ce que l’analyse du code avec
l’Assistant Mise à niveau .NET ?
Article • 31/10/2024

Cet article fournit une vue d’ensemble de la fonction d’analyse du code de l’Assistant
Mise à niveau .NET. L’analyse du code génère un rapport basé sur la configuration, les
dépendances et le code de votre projet. Le rapport contient des informations sur les
problèmes potentiels et les problèmes que vous pouvez rencontrer pendant la mise à
niveau, ainsi que les étapes à suivre pour corriger ces problèmes.

Types d’analyse
Il existe deux types d’analyse que vous pouvez effectuer sur votre code :

Code source et paramètres

Analyse votre code source, votre configuration et vos paramètres.

Dépendances binaires

Analyse les dépendances binaires externes (telles que les packages NuGet) pour
vos projets.

Rapports
Un rapport de tableau de bord est généré une fois l’analyse terminée. Ce rapport
décompose les résultats par projet, fichier, incident et points d’histoire. Une vue
d’agrégation est également disponible pour regrouper les problèmes similaires, quel
que soit le projet dans lequel ils ont été détectés.

 Conseil

Les points d’histoire sont un concept Agile qui permet d’estimer la complexité et
l’effort requis pour résoudre un problème. Pour plus d’informations, consultez la
section Points de l’histoire des incidents.

Chaque problème dans le rapport est classé par gravité pour vous aider à hiérarchiser
les correctifs que vous devez effectuer. Les problèmes sont obligatoires ou facultatifs.
Les problèmes obligatoires bloquent la mise à niveau. Les problèmes facultatifs offrent
la possibilité de procéder à une mise à niveau vers une fonctionnalité, une bibliothèque
ou une amélioration du code plus récente.

Les sections suivantes décrivent en détail les zones du rapport.

Tableau de bord
La page Tableau de bord fournit une vue des incidents détectés par l’analyse,
regroupées dans des panneaux :

Résumé

Projets

Il s’agit du nombre de projets où un incident a été détecté.

Problèmes

Nombre de règles uniques qui se sont déclenchées pendant l’analyse. Chaque

problème a sa propre gravité et son point d’histoire, ainsi que chaque instance
détectée (incident).

Incidents

Un incident est une instance d’un problème détecté à un emplacement

spécifique, tel qu’un élément de code ou un fichier binaire. Chaque incident
 contient les informations contextuelles qui ont déclenché le problème.

Story Points

Nombre total de points d’article requis pour terminer la mise à niveau. Pour plus
d’informations sur ce qu’est un point d’histoire, consultez la section Points de
l’histoire de l’incident.

Gravité et catégories

Ces deux panneaux affichent des graphiques qui regroupent les incidents par
gravité et par catégorie. Pour plus d’informations sur la gravité, consultez la section
Gravité de l’incident.

Projets
La page Projets décompose les problèmes, incidents et points d’histoire, par projet.
Chaque projet est un lien qui ouvre un rapport d’extraction filtré sur ce projet.

Problèmes d’agrégation
La page Problèmes d’agrégation détaille chaque problème déclenché. Chaque
problème peut être développé pour répertorier chaque incident de ce problème. La
colonne État vous aide à suivre les problèmes que vous avez résolus ou jugés non
applicables.
Gravité de l’incident
Chaque incident de problème a une gravité associée, ce qui peut bloquer la mise à
niveau. La gravité vous aide à comprendre ce qui doit être mis à jour pour que la mise à
niveau réussisse.

ﾉ Agrandir le tableau

Niveau de Description
gravité

Obligatoire Doit être traité. Le processus de mise à niveau peut gérer ces problèmes pour
vous, tels que la mise à jour du runtime du framework cible (TFM).

Facultatif Celles-ci ne doivent pas poser de problème avec la mise à niveau, mais vous
pouvez envisager de les traiter avant ou après la mise à niveau.

Potential Problèmes susceptibles de provoquer un problème après la mise à niveau, si

vous ne les résolvez pas maintenant.

Information Informations supplémentaires relatives à la mise à niveau.

Points d’histoire d’incident

Chaque incident de problème a un point de récit associé. Un point d’histoire est une
unité de mesure permettant de mesurer la complexité d’un incident, ce qui permet
d’estimer le temps nécessaire pour résoudre cet incident. L’Assistant Mise à niveau .NET
définit des valeurs de point de montage par le tableau suivant :

ﾉ Agrandir le tableau
Story points Taille

1 Simple

3 Complex

5 Refonte

7 Réarchitecture

13 Inconnu

Contenu connexe
Analyser des projets avec l’Assistant Mise à niveau .NET
Analyser des projets avec l’Assistant
Mise à niveau .NET
Article • 31/01/2025

Cet article explique comment effectuer une analyse du code sur vos projets avec
l’Assistant Mise à niveau .NET, à l’aide de Visual Studio ou du terminal. L’analyse génère
un rapport que vous pouvez rechercher pour obtenir plus d’informations sur la mise à
niveau.

Prérequis
Pour Visual Studio, consultez Installer l’Assistant Mise à niveau .NET - Extension
Visual Studio.
Pour l'outil global .NET, consultez Installer l'Assistant de Mise à niveau .NET - Outil
global .NET.

Créer un rapport dans Visual Studio

Suivez ces étapes pour analyser un projet dans Visual Studio.

1. Ouvrez Visual Studio.

2. Ouvrez un projet ou une solution.

3. Dans la fenêtre Explorateur de solutions, cliquez avec le bouton droit sur la mise à
niveau de la solution>.
4. Sous l’onglet Assistant Mise à niveau : Accueil , sélectionnez Nouveau rapport.

5. Sélectionnez un ou plusieurs projets à analyser, puis sélectionnez Suivant.

6. Sélectionnez le framework cible, par exemple .NET 8.0. Sélectionnez ensuite
Suivant.

7. Sélectionnez les composants à analyser, puis sélectionnez Suivant.

8. Un indicateur de progression s’affiche pour chaque projet analysé.

9. Une fois l’analyse terminée, le tableau de bord du rapport s’affiche. Pour plus
d’informations sur le tableau de bord, consultez Rapports.
Créer un rapport à partir de l’interface CLI
Suivez ces étapes pour analyser un projet à l’aide du terminal. L’outil global .NET est un
outil interactif qui vous guide tout au long des options d’analyse. Utilisez les touches

Flèche haut et Bas pour modifier l’option mise en surbrillance, puis Entrez pour
exécuter l’option Sélectionner l’option. Chaque écran vous présente des options sur la
façon dont vous souhaitez configurer le rapport.

1. Ouvrez un terminal et accédez au dossier contenant la solution ou le projet que

vous souhaitez analyser.

2. Pour démarrer l’outil, exécutez la upgrade-assistant analyze commande.

3. Vous êtes invité à savoir ce que vous voulez analyser. Pour cet exemple, choisissez
les sources d’application et appuyez sur Entrée .
 4. Choisissez un framework cible, tel que .NET 8.0, puis appuyez sur Entrée .

5. Sélectionnez les types d’éléments que vous souhaitez analyser. Utilisez espace

pour activer/désactiver les options, puis appuyez sur Entrée .

6. Dans l’écran fichier de configuration, appuyez sur n , sauf si vous avez un fichier
de configuration d’ensemble de règles à appliquer.

7. Choisissez le format du rapport généré. Pour les besoins de cet exemple,

sélectionnez Enregistrer en tant que HTML.

8. Entrez le nom MyReport , puis appuyez sur Entrée .

9. Sélectionnez le mode de confidentialité approprié, tel que Restreint et appuyez sur

Entrée .

10. L’invite finale est une confirmation, affichant toutes les options que vous avez
sélectionnées. Appuyez sur Entrée pour exécuter l’analyse et générer le rapport.
11. Une fois le rapport terminé, un résumé du rapport s’affiche. Les résultats du
rapport sont enregistrés dans le dossier du projet ou de la solution qui a été
analysé.

Contenu connexe
Qu’est-ce que l’analyse du code avec l’Assistant Mise à niveau .NET ?
Qu’est-ce que l’Assistant Mise à niveau .NET ?
Installer l’Assistant Mise à niveau .NET
Effectuer une mise à niveau d’ASP.NET
MVC et de l’API web vers ASP.NET
Core MVC
Article • 06/11/2024

Cet article explique comment mettre à niveau une application ASP.NET Framework MVC
ou API web vers ASP.NET Core MVC à l’aide de l’Assistant Mise à niveau de .NET de
Visual Studio et de l’approche de mise à jour incrémentielle.

Mettre à niveau à l’aide de l’Assistant Mise à

niveau de .NET
Si votre projet .NET Framework a des bibliothèques de prise en charge dans sa solution
qui sont requises, elles doivent être mises à niveau vers .NET Standard 2.0, si possible.
Pour plus d’informations, consultez l’article Mettre à niveau les bibliothèques de prise en
charge.

1. Installez l’extension Visual Studio Assistant Mise à niveau de .NET .

2. Ouvrez la solution ASP.NET MVC ou API web dans Visual Studio.
3. Dans l’Explorateur de solutions, cliquez avec le bouton droit sur le projet à mettre
à niveau, puis sélectionnez Mettre à niveau. Sélectionnez Mise à niveau de projet
incrémentielle côte à côte, qui est la seule option de mise à niveau.
4. Pour la cible de mise à niveau, sélectionnez Nouveau projet.
5. Nommez le projet et sélectionnez le modèle souhaité. Si le projet que vous migrez
est un projet d’API, sélectionnez API web ASP.NET Core. S’il s’agit d’un projet MVC
ou MVC et API web, sélectionnez ASP.NET Core MVC.
6. Sélectionnez Suivant.
7. Sélectionnez la version du framework cible, puis sélectionnez Suivant. Pour plus
d’informations, consultez l’article Stratégie de prise en charge de .NET et
.NET Core .
8. Consultez le récapitulatif des changements, puis sélectionnez Terminer.
9. L’étape Résumé indique que <Framework Project> est désormais connecté à
<Framework ProjectCore> par le biais d’un proxy Yarp. Un graphique à secteurs

montre les points de terminaison migrés. Sélectionnez Mettre à niveau le

contrôleur, puis sélectionnez un contrôleur à mettre à niveau.
10. Sélectionnez le composant à mettre à niveau, puis sélectionnez Mettre à niveau la
sélection.
Mise à jour incrémentielle
Suivez les étapes décrites dans Prise en main de la migration incrémentielle d’ASP.NET
vers ASP.NET Core afin de poursuivre le processus de mise à jour.
Mise à niveau d’une application de
bureau WPF vers .NET 8
Article • 05/11/2024

Cet article explique comment mettre à niveau une application de bureau Windows
Presentation Foundation (WPF) vers .NET 8. Même si WPF s’exécute sur .NET, une
technologie multiplateforme, WPF est toujours un framework Windows uniquement. Les
types de projets wpF suivants peuvent être mis à niveau avec l’Assistant Mise à niveau
.NET :

Projet WPF
Bibliothèque de contrôles
Bibliothèque .NET

Si vous effectuez une mise à niveau de .NET Framework vers .NET, examinez l’article
Différences avec WPF .NET et le guide de portage de .NET Framework vers .NET .

Prérequis
Système d’exploitation Windows
Visual Studio 2022 version 17.7 ou ultérieure pour cibler .NET 8
Visual Studio 2022 version 17.1 ou ultérieure pour cibler .NET 7
Extension Assistant Mise à niveau .NET pour Visual Studio

Application de démonstration
Cet article a été écrit dans le contexte de la mise à niveau de l’exemple de projet Favoris
web, que vous pouvez télécharger à partir du dépôt GitHub d’exemples .NET.

Lancer la mise à niveau

Si vous mettez à niveau plusieurs projets, commencez par des projets qui n’ont aucune
dépendance. Dans l’exemple Favoris web, le projet WebSiteRatings dépend de la
bibliothèque StarVoteControl. StarVoteControl doit donc être mis à niveau en premier.

 Conseil
 Veillez à disposer d’une sauvegarde de votre code, par exemple dans le contrôle de
code source ou une copie.

Procédez comme suit pour mettre à niveau un projet dans Visual Studio :

1. Cliquez avec le bouton droit sur le projet StarVoteControl dans la fenêtre

Explorateur de solutions, puis sélectionnez Mettre à niveau :

Un nouvel onglet est ouvert qui vous invite à choisir la façon dont vous souhaitez
que la mise à niveau soit effectuée.

2. Sélectionnez Mise à niveau de projet sur place.

3. Ensuite, sélectionnez l’infrastructure cible. En fonction du type de projet que vous

mettez à niveau, différentes options sont présentées. .NET Standard 2.0 est un bon
choix si la bibliothèque ne s’appuie pas sur une technologie de bureau comme
WPF et peut être utilisée par les projets .NET Framework et les projets .NET.
Toutefois, les dernières versions de .NET fournissent de nombreuses améliorations
du langage et du compilateur sur .NET Standard.

Sélectionnez .NET 8.0 , puis sélectionnez Suivant.

4. Une arborescence s’affiche avec tous les artefacts liés au projet, tels que les fichiers
de code et les bibliothèques. Vous pouvez mettre à niveau des artefacts individuels
ou l’ensemble du projet, qui est la valeur par défaut. Sélectionnez Mettre à niveau
la sélection pour démarrer la mise à niveau.

Une fois la mise à niveau terminée, les résultats sont affichés :

 Les artefacts avec un cercle vert unie ont été mis à niveau alors que les cercles
verts vides ont été ignorés. Les artefacts ignorés signifient que l’Assistant mise à
niveau n’a rien trouvé à mettre à niveau.

Maintenant que la bibliothèque de prise en charge de l’application est mise à niveau,

mettez à niveau l’application principale.

Mettre à niveau l’application

Une fois que toutes les bibliothèques de prise en charge sont mises à niveau, le projet
d’application principal peut être mis à niveau. Appliquez la procédure suivante :

1. Cliquez avec le bouton droit sur le projet WebSiteRatings dans la fenêtre

Explorateur de solutions, puis sélectionnez Mettre à niveau :
2. Sélectionnez Mise à niveau du projet sur place comme mode de mise à niveau.
3. Sélectionnez .NET 8.0 pour le framework cible, puis sélectionnez Suivant.
4. Laissez tous les artefacts sélectionnés et sélectionnez Mettre à niveau la sélection.

Une fois la mise à niveau terminée, les résultats sont affichés. Si un élément a un
symbole d’avertissement, cela signifie qu’il existe une note à lire, que vous pouvez faire
en développant l’élément.

Générer une build propre

Une fois votre projet mis à niveau, propre et le compiler.
 1. Cliquez avec le bouton droit sur le projet WebSiteRatings dans la fenêtre
Explorateur de solutions, puis sélectionnez Nettoyer.
2. Cliquez avec le bouton droit sur le projet WebSiteRatings dans la fenêtre
Explorateur de solutions, puis sélectionnez Générer.

Si votre application a rencontré des erreurs, vous pouvez les trouver dans la fenêtre
Liste d’erreurs avec une recommandation pour les corriger.

Étapes post-mise à niveau

Si votre projet est mis à niveau de .NET Framework vers .NET, passez en revue les
informations de la modernisation après la mise à niveau vers .NET à partir de l’article
.NET Framework .

Après la mise à niveau, vous devez :

Vérifiez vos packages NuGet.

L’Assistant Mise à niveau .NET a mis à niveau certains packages vers de nouvelles
versions. Avec l’exemple d’application fourni dans cet article, le
Microsoft.Data.Sqlite package NuGet a été mis à niveau de 1.0.0 à 8.0.x.

Toutefois, la version 1.0.0 dépend du SQLite package NuGet, mais la version 8.0.x
supprime cette dépendance. Le SQLite package NuGet est toujours référencé par
le projet, même s’il n’est plus nécessaire. Les SQLite packages NuGet et
SQLite.Native NuGet peuvent être supprimés du projet.

Nettoyez les anciens packages NuGet.

Le fichier packages.config n’est plus nécessaire et peut être supprimé de votre

projet, car les références de package NuGet sont désormais déclarées dans le
fichier projet. En outre, le dossier de cache de package NuGet local, nommé
Packages, se trouve dans le dossier ou le dossier parent du projet. Ce dossier de
cache local peut être supprimé. Les nouvelles références de package NuGet
utilisent un dossier de cache global pour les packages, disponible dans le
répertoire de profil de l’utilisateur, nommé .nuget\packages.

Supprimez la System.Configuration bibliothèque.

La plupart des applications .NET Framework font référence à la

System.Configuration bibliothèque. Après la mise à niveau, il est possible que

cette bibliothèque soit toujours directement référencée.

 La System.Configuration bibliothèque utilise le fichier app.config pour fournir des
options de configuration au moment de l’exécution à votre application. Pour .NET,
cette bibliothèque a été remplacée par le
System.Configuration.ConfigurationManager package NuGet. Supprimez la

référence à la bibliothèque et ajoutez le package NuGet à votre projet.

Recherchez des emplacements pour moderniser votre application.

Les API et les bibliothèques ont changé un peu depuis la publication de .NET. Dans
la plupart des cas, .NET Framework n’a pas accès à ces améliorations. En effectuant
une mise à niveau vers .NET, vous avez désormais accès à des bibliothèques plus
modernes.

Les sections suivantes décrivent les zones que vous moderniserez l’exemple
d’application utilisé par cet article.

Moderniser : contrôle de navigateur Web

Le WebBrowser contrôle référencé par l’exemple d’application WPF est basé sur Internet
Explorer, qui est obsolète. WPF pour .NET peut utiliser le contrôle WebView2 basé sur
Microsoft Edge. Effectuez les étapes suivantes pour effectuer la mise à niveau vers le
nouveau WebView2 contrôle de navigateur Web :

1. Ajoutez le package NuGet Microsoft.Web.WebView2 .

2. Dans le fichier MainWindow.xaml :

a. Importez le contrôle dans l’espace de noms wpfControls dans l’élément racine :

XAML

<mah:MetroWindow x:Class="WebSiteRatings.MainWindow"

xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
xmlns:mc="http://schemas.openxmlformats.org/markup-
compatibility/2006"
xmlns:mah="clr-
namespace:MahApps.Metro.Controls;assembly=MahApps.Metro"
xmlns:local="clr-namespace:WebSiteRatings"
xmlns:vm="clr-namespace:WebSiteRatings.ViewModels"
xmlns:VoteControl="clr-
namespace:StarVoteControl;assembly=StarVoteControl"
xmlns:wpfControls="clr-
namespace:Microsoft.Web.WebView2.Wpf;assembly=Microsoft.Web.WebView2
.Wpf"
 Loaded="MetroWindow_Loaded"
mc:Ignorable="d"
Title="My Sites" Height="650" Width="1000">

b. Vers le bas où l’élément <Border> est déclaré, supprimez le WebBrowser contrôle

et remplacez-le par le wpfControls:WebView2 contrôle :

XAML

<Border Grid.Row="2" Grid.Column="1" Grid.ColumnSpan="2"

BorderThickness="1" BorderBrush="Black" Margin="5">
<wpfControls:WebView2 x:Name="browser"
ScrollViewer.CanContentScroll="True" />
</Border>

3. Modifiez le fichier de code arrière MainWindow.xaml.cs. Mettez à jour la

ListBox_SelectionChanged méthode pour définir la browser.Source propriété sur

un valide Uri. Ce code était précédemment passé dans l’URL du site Web sous la
forme d’une chaîne, mais le WebView2 contrôle nécessite un Uri .

C#

private void ListBox_SelectionChanged(object sender,

SelectionChangedEventArgs e)
{
var siteCollection = (ViewModels.SiteCollection)DataContext;

if (siteCollection.SelectedSite != null)
browser.Source = new Uri(siteCollection.SelectedSite.Url);
else
browser.NavigateToString("<body></body>");
}

Selon la version de Windows qu’un utilisateur de votre application exécute, il peut avoir
besoin d’installer le runtime WebView2. Pour plus d’informations, consultez Démarrage
de WebView2 dans les applications WPF.

Moderniser : appsettings.json
.NET Framework utilise le fichier App.config pour charger les paramètres de votre
application, tels que les chaînes de connexion et les fournisseurs de journalisation. .NET
utilise désormais le fichier appsettings.json pour les paramètres de l’application. Les
fichiers App.config sont pris en charge dans .NET via le
System.Configuration.ConfigurationManager package NuGet, et la prise en charge de

appsettings.json est fournie par le Microsoft.Extensions.Configuration package NuGet.

À mesure que d’autres bibliothèques sont mises à niveau vers .NET, elles se modernisent
en prenant en charge appsettings.json au lieu de App.config. Par exemple, les
fournisseurs de journalisation dans .NET Framework qui ont été mis à niveau pour
.NET 6+ n’utilisent plus App.config pour les paramètres. Il est bon de suivre leur direction
et de s’éloigner de l’utilisation d’App.config où vous pouvez.

Utiliser appsettings.json avec l’exemple d’application WPF

Par exemple, après la mise à niveau de l’exemple d’application WPF, utilisez
appsettings.json pour le chaîne de connexion vers la base de données locale.

1. Supprimez le System.Configuration.ConfigurationManager package NuGet.

2. Ajoutez le package NuGet Microsoft.Extensions.Configuration.Json .

3. Ajoutez un fichier au projet nommé appsettings.json.

4. Définissez le fichier appsettings.json à copier dans le répertoire de sortie.

Définissez la copie sur le paramètre de sortie via Visual Studio à l’aide de la

fenêtre Propriétés après avoir sélectionné le fichier dans le Explorateur de
solutions. Vous pouvez également modifier le projet directement et ajouter les
éléments suivants ItemGroup :

XML

<ItemGroup>
<Content Include="appsettings.json">
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</Content>
</ItemGroup>

5. Migrez les paramètres dans le fichier App.config vers un nouveau fichier

appsettings.json .

Dans l’exemple d’application WPF, app.config ne contenait qu’une seule chaîne de

connexion. Modifiez le fichier appsettings.json pour définir le chaîne de connexion :

JSON

{
"ConnectionStrings": {
 "database": "DataSource=sqlite.db;"
}
}

6. Modifiez le fichier App.xaml.cs , instanciant un objet de configuration qui charge le

fichier appsettings.json , les lignes ajoutées sont mises en surbrillance :

C#

using System.Windows;
using Microsoft.Extensions.Configuration;

namespace WebSiteRatings
{
/// <summary>
/// Interaction logic for App.xaml
/// </summary>
public partial class App : Application
{
public static IConfiguration Config { get; private set; }

public App()
{
Config = new ConfigurationBuilder()
.AddJsonFile("appsettings.json")
.Build();
}
}
}

7. Dans le fichier .\Models\Database.cs, modifiez la OpenConnection méthode pour

utiliser la nouvelle App.Config propriété. Cela nécessite l’importation de l’espace
Microsoft.Extensions.Configuration de noms :

C#

using Microsoft.Data.Sqlite;
using System.Collections.Generic;
using Microsoft.Extensions.Configuration;

namespace WebSiteRatings.Models
{
internal class Database
{
public static SqliteConnection OpenConnection() =>
new
SqliteConnection(App.Config.GetConnectionString("database"));

public static IEnumerable<Site> ReadSites()

GetConnectionString est une méthode d’extension fournie par l’espace de
Microsoft.Extensions.Configuration noms.
Migrer du .NET Framework Windows
Forms vers .NET
Article • 03/12/2024

Cet article explique comment mettre à niveau une application de bureau Windows
Forms vers .NET à l’aide de l’Assistant Mise à niveau .NET. Windows Forms reste une
infrastructure Windows uniquement, même si .NET est une technologie multiplateforme.

Prérequis
Système d’exploitation Windows.
Téléchargez et extrayez l’application de démonstration utilisée avec cet article.
Visual Studio 2022 version 17.12 ou ultérieure pour cibler .NET 9.
Extension De l’Assistant Mise à niveau .NET pour Visual Studio.

Évaluation
Vous devez analyser vos projets avant d’effectuer une mise à niveau. L’exécution d’une
analyse du code sur vos projets avec l’Assistant Mise à niveau .NET génère un rapport
auquel vous pouvez vous référer pour identifier les bloqueurs de migration potentiels.

Pour analyser vos projets et générer un rapport, cliquez avec le bouton droit sur le
fichier solution dans Explorateur de solutions, puis sélectionnez Mettre à niveau. Pour
plus d’informations sur l’exécution d’une analyse, consultez Analyser des projets avec
l’Assistant Mise à niveau .NET.

Migrer des dépendances

Si vous mettez à niveau plusieurs projets, commencez par des projets qui n’ont aucune
dépendance. Dans l’exemple De jeu correspondant, le projet MatchingGame dépend de
la bibliothèque MatchingGame.Logic . Par conséquent , MatchingGame.Logic doit
d’abord être mis à niveau.

 Conseil

Veillez à disposer d’une sauvegarde de votre code, par exemple dans le contrôle de
code source ou une copie.
Procédez comme suit pour mettre à niveau un projet dans Visual Studio :

1. Cliquez avec le bouton droit sur le projet MatchingGame.Logic dans la fenêtre

Explorateur de solutions, puis sélectionnez Mettre à niveau :

Un nouvel onglet est ouvert qui vous invite à choisir la mise à niveau que vous
souhaitez effectuer.

2. Sélectionnez Mise à niveau de projet sur place.

3. Ensuite, sélectionnez l’infrastructure cible.

En fonction du type de projet que vous mettez à niveau, vous disposez de

différentes options. .NET Standard 2.0 peut être utilisé par .NET Framework et
.NET. Il s’agit d’un bon choix si la bibliothèque ne s’appuie pas sur une technologie
de bureau comme Windows Forms, que ce projet fait.
 Sélectionnez .NET 9.0 , puis sélectionnez Suivant.

4. Une arborescence s’affiche avec tous les artefacts liés au projet, tels que les fichiers
de code et les bibliothèques. Vous pouvez mettre à niveau des artefacts individuels
ou l’ensemble du projet, qui est la valeur par défaut. Sélectionnez Mettre à niveau
la sélection pour démarrer la mise à niveau.

5. Une fois la mise à niveau terminée, les résultats sont affichés :

 Les artefacts avec un cercle vert unie ont été mis à niveau alors que les cercles
verts vides ont été ignorés. Les artefacts ignorés signifient que l’Assistant mise à
niveau n’a rien trouvé à mettre à niveau.

Maintenant que la bibliothèque de prise en charge de l’application est mise à niveau,

mettez à niveau l’application principale.

Remarques pour les projets Visual Basic

Actuellement, l’Assistant Mise à niveau .NET ne reconnaît pas l’utilisation du fichier de
System.Configuration paramètres créé par les modèles Visual Basic sur .NET Framework.

Il ne respecte pas également l’utilisation des extensions utilisées dans les My projets
.NET Framework, tels que My.Computer et My.User . Ces extensions ont été supprimées
dans .NET. En raison de ces deux problèmes, une bibliothèque Visual Basic ne sera pas
compilée après la migration avec l’Assistant Mise à niveau .NET.

Pour résoudre ce problème, le projet doit cibler Windows et référencer Windows Forms.

1. Une fois la migration terminée, double-cliquez sur le projet MatchingGame.Logic

dans la fenêtre Explorateur de solutions.
2. Recherchez l’élément <Project>/<PropertyGroup> .
3. Dans l’éditeur XML, remplacez la valeur par <TargetFramework> net9.0 net9.0-
windows .

4. Ajouter <UseWindowsForms>true</UseWindowsForms> à la ligne après

<TargetFramework> .

Les paramètres du projet doivent ressembler à l’extrait de code suivant :

 XML

<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net9.0-windows</TargetFramework>
<UseWindowsForms>true</UseWindowsForms>
<OutputType>Library</OutputType>
<MyType>Windows</MyType>

... other settings removed for brevity ...

Migrer le projet principal

Une fois que toutes les bibliothèques de prise en charge sont mises à niveau, le projet
d’application principal peut être mis à niveau. Avec l’exemple d’application, il n’existe
qu’un seul projet de bibliothèque à mettre à niveau, qui a été mis à niveau dans la
section précédente.

1. Cliquez avec le bouton droit sur le projet MatchingGame dans la fenêtre

Explorateur de solutions, puis sélectionnez Mettre à niveau :
2. Sélectionnez Mise à niveau de projet sur place.
3. Sélectionnez .NET 9.0 pour le framework cible, puis sélectionnez Suivant.
4. Laissez tous les artefacts sélectionnés et sélectionnez Mettre à niveau la sélection.

Une fois la mise à niveau terminée, les résultats sont affichés. Notez comment le projet
Windows Forms a un symbole d’avertissement. Développez cet élément et plus
d’informations s’affichent à propos de cette étape :
Notez que le composant de mise à niveau du projet mentionne que la police par défaut
a changé. Étant donné que la police peut affecter la disposition du contrôle, vous devez
vérifier chaque formulaire et contrôle personnalisé dans votre projet pour vous assurer
que l’interface utilisateur est correctement organisée.

Générer une build propre

Une fois votre projet principal mis à niveau, nettoyez et compilez-le.

1. Cliquez avec le bouton droit sur le projet MatchingGame dans la fenêtre

Explorateur de solutions, puis sélectionnez Nettoyer.
2. Cliquez avec le bouton droit sur le projet MatchingGame dans la fenêtre
Explorateur de solutions, puis sélectionnez Générer.

Si votre application a rencontré des erreurs, vous pouvez les trouver dans la fenêtre
Liste d’erreurs avec une recommandation pour les corriger.

L’exemple de projet de jeu correspondant Windows Forms est désormais mis à niveau
vers .NET 9.

Expérience post-mise à niveau

Si vous transférez une application de .NET Framework vers .NET, passez en revue la
modernisation après la mise à niveau vers .NET à partir de l’article .NET Framework .
Contenu connexe
Portage de .NET Framework vers .NET.

Le guide de portage 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. La
complexité de vos projets détermine la quantité de travail que vous allez effectuer
après la migration initiale des fichiers projet.

Moderniser après la mise à niveau vers .NET à partir de .NET Framework.

Le monde de .NET a beaucoup changé depuis .NET Framework. Ce lien fournit des
informations sur la modernisation de votre application après la mise à niveau.
Migrer d’UWP vers le SDK d’application
Windows avec l’Assistant Mise à niveau
.NET
Article • 09/10/2023

L’Assistant Mise à niveau .NET (consultez Vue d’ensemble de l’Assistant Mise à niveau
.NET) est une extension Visual Studio (recommandée), et un outil en ligne de
commande, qui peut vous aider à migrer une application de plateforme Windows
universelle (UWP) C# vers une application de la Bibliothèque d’interface utilisateur
Windows (WinUI) 3 utilisant le SDK d’application Windows.

Notre feuille de route pour la prise en charge d’UWP dans l’Assistant Mise à niveau .NET
comprend d’autres améliorations d’outils et la prise en charge de la migration pour les
nouvelles fonctionnalités. Si vous rencontrez des problèmes liés à l’Assistant Mise à
niveau .NET, vous pouvez les signaler dans Visual Studio en sélectionnant Aide>Envoyer
des commentaires>Signaler un problème.

Consultez également le dépôt GitHub de l’Assistant Mise à niveau . Les options

d’exécution de l’outil sur la ligne de commande sont documentées ici.

Installer l’Assistant Mise à niveau de .NET

Vous pouvez installer l’Assistant Mise à niveau .NET comme une extension Visual Studio
ou un outil en ligne de commande .NET. Pour plus d’informations, consultez Installer
l’Assistant Mise à niveau .NET.

Résumé
Quand vous utilisez l’Assistant Mise à niveau .NET pour migrer votre application UWP,
voici les étapes générales et les phases du processus de migration effectuées par l’outil.

Copie éventuellement votre projet et migre la copie : laisse votre projet d’origine
inchangé.
Migre éventuellement votre projet sur place (dans les mêmes dossiers et fichiers,
sans renommer les dossiers) : ne fait pas de copie.
Met à niveau votre projet du format .NET Framework vers le dernier format de
projet SDK .NET.
 Nettoie les références de package NuGet. En plus des packages référencés par
votre application, le fichier packages.config contient des références aux
dépendances de ces packages. Par exemple, si vous avez ajouté une référence au
package A, qui dépend du package B, les deux packages sont référencés dans le
fichier packages.config . Dans le nouveau système de projet, seule la référence au
package A est nécessaire. Cette étape analyse les références de package et
supprime celles qui ne sont pas nécessaires. Votre application fait néanmoins
toujours référence aux assemblys .NET Framework. Certains de ces assemblys
peuvent être disponibles sous forme de packages NuGet. Cette étape analyse ces
assemblys et référence le package NuGet approprié.
Cible .NET 6 et le SDK d’application Windows.
Remplace le moniker de framework cible (TFM) (consultez Frameworks cibles dans
les projets de style SDK) .NET Framework par le SDK suggéré. Par exemple, net6.0-
windows

Migre votre code source UWP de WinUI 2 vers WinUI 3, en effectuant les
changements de code propres à la source.
Ajoute/met à jour tous les fichiers de modèle, de configuration et de code. Par
exemple, ajoute les profils de publication nécessaires, App.xaml.cs ,
MainWindow.xaml.cs , MainWindow.xaml et autres.

Met à jour les espaces de noms et ajoute la navigation MainPage.

Tente de détecter et corriger les API qui sont différentes entre UWP et le SDK
d’application Windows, et utilise les éléments TODO de la Liste des tâches pour
marquer les API qui ne sont plus prises en charge.

Pendant son exécution, l’outil donne également des conseils de migration sous la forme
de messages d’avertissement dans la sortie de l’outil, et des éléments TODO de la Liste
des tâches sous la forme de commentaires dans le code source de votre projet (par
exemple, quand une migration entièrement automatisée de votre code source UWP
n’est pas possible). Un élément TODO de la Liste des tâches classique comprend un lien
vers une rubrique dans cette documentation de migration. En tant que développeur,
vous contrôlez toujours le processus de migration.

 Conseil

Pour voir tous les éléments TODO générés par l’outil, consultez la Liste des tâches
dans Visual Studio.

７ Notes
 Une fois l’exécution de l’outil terminée, vous pouvez choisir d’effectuer certaines
étapes de suivi si nécessaire. Vous pouvez déplacer votre code de App.xaml.old.cs
vers App.xaml.cs , et vous pouvez restaurer AssemblyInfo.cs à partir de la
sauvegarde créée par l’outil.

Ce que l’outil prend en charge

Cette version de l’Assistant Mise à niveau .NET est actuellement en préversion et reçoit
des mises à jour fréquentes. Actuellement, l’outil prend uniquement en charge le
langage de programmation C#, et pas C++. Dans la plupart des cas, avec cette version,
votre projet nécessite des efforts supplémentaires de votre part pour terminer la
migration.

L’outil migre votre projet ainsi que votre code pour qu’il soit compilé. Toutefois,
certaines fonctionnalités demandent une investigation et une correction (via les
éléments TODO de la Liste des tâches). Pour plus d’informations sur les éléments à
prendre en compte avant la migration, consultez Éléments pris en charge pendant la
migration d’UWP vers WinUI 3.

En raison des limitations suivantes de la version actuelle de l’Assistant Mise à niveau

.NET, vous pouvez choisir d’attendre une version ultérieure avant de migrer votre
application :

La migration à partir des API ApplicationView n’est pas prise en charge.

La migration à partir d’API liées à AppWindow n’est pas prise en charge.

Si possible, l’outil tente de générer un avertissement, et cela bloque intentionnellement

la compilation de votre code tant que vous ne le changez pas.

Les vues personnalisées ne sont pas prises en charge. Par exemple, vous ne recevez
pas d’avertissement ou de correctif pour une boîte de dialogue personnalisée qui
étend MessageDialog et appelle une API de manière incorrecte.
Les composants Windows Runtime ne sont pas pris en charge.

Les applications multifenêtres peuvent ne pas être migrées correctement.

Un projet qui suit une structure de fichier non standard (par exemple, App.xaml et
App.xaml.cs qui ne sont pas dans le dossier racine) peut ne pas être migré

correctement.

Le dépôt GitHub de l’Assistant Mise à niveau documente des conseils de résolution de

problèmes et les problèmes connus. Si vous rencontrez des problèmes pendant
l’utilisation de l’outil, signalez-les dans ce même dépôt GitHub, en leur appliquant
l’étiquette de domaine UWP . Nous vous en sommes reconnaissants !

７ Notes

Pour obtenir des conseils sur le processus de migration (et connaître les différences
entre les fonctionnalités et les API UWP/SDK d’application Windows), consultez
Migrer d’UWP vers le SDK d’application Windows.

 Conseil

Vous pouvez voir votre version de l’outil en envoyant la commande upgrade-

assistant --version .

Évaluer l’outil avec l’exemple d’application UWP

PhotoLab
Prenons l’Assistant Mise à niveau .NET pour une version d’évaluation.

Comme matériel source, nous migrons l’exemple d’application UWP PhotoLab .

PhotoLab est un exemple d’application permettant de consulter et de modifier des
fichiers image. Il illustre les fonctionnalités XAML de disposition, de liaison de données
et de personnalisation de l’interface utilisateur.

７ Notes

Vous pouvez voir une étude de cas de l’exemple PhotoLab migré entièrement
manuellement dans Migration vers le SDK d’application Windows de l’exemple
d’application UWP PhotoLab.

1. Commencez par cloner ou télécharger le code source de l’exemple PhotoLab à

partir du lien ci-dessus.

 Conseil

N’oubliez pas qu’une fois que nous avons utilisé l’outil pour automatiser la
migration de l’application, des efforts manuels supplémentaires sont nécessaires
pour terminer la migration.
 1. Ouvrez la solution PhotoLab dans Visual Studio.

2. Après avoir installé l’extension de l’Assistant Mise à niveau .NET (consultez Installer
l’Assistant Mise à niveau .NET plus haut dans cette rubrique), cliquez avec le
bouton droit sur le projet dans l’Explorateur de solutions, puis cliquez sur Mettre
à niveau.

3. Choisissez l’option Mettre à niveau le projet vers une version .NET plus récente.

4. Choisissez l’option Mise à niveau de projet sur place.

5. Choisissez un framework cible.

6. Cliquez sur Mettre à niveau la sélection.

7. L’Assistant Mise à niveau .NET s’exécute et utilise la fenêtre Sortie de Visual Studio
pour imprimer les informations et l’état de progression.

Vous pouvez monitorer la barre de progression jusqu’à ce que l’opération de mise à

niveau soit terminée.

La migration de code de l’exemple d’application PhotoLab comprend les éléments

suivants :

Changements des API Content Dialog et File Save Picker.

Mise à jour XAML du package Animations.
Affichage des messages d’avertissement et ajout d’éléments TODO de la Liste des
tâches dans DetailPage.xaml , DetailPage.xaml.cs et MainPage.xaml.cs pour le
bouton Précédent personnalisé.
Implémentation de la fonctionnalité du bouton Précédent et ajout d’un élément
TODO de la Liste des tâches pour personnaliser le bouton XAML.
Vous avez accès à un lien vers la documentation pour en savoir plus sur
l’implémentation du bouton Précédent.

Les numéros de version de votre .csproj résultant sont légèrement différents, mais
ressemblent essentiellement à ceci (avec certains groupes de propriétés de
configuration de build supprimés par souci de concision) :

XML

<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net6.0-windows10.0.19041.0</TargetFramework>
<Platform Condition=" '$(Platform)' == '' ">x86</Platform>
<OutputType>WinExe</OutputType>
<DefaultLanguage>en-US</DefaultLanguage>
 <TargetPlatformMinVersion>10.0.17763.0</TargetPlatformMinVersion>
<RuntimeIdentifiers>win10-x86;win10-x64;win10-arm64</RuntimeIdentifiers>
<UseWinUI>true</UseWinUI>
<ApplicationManifest>app.manifest</ApplicationManifest>
<EnableMsixTooling>true</EnableMsixTooling>
<Platforms>x86;x64;arm64</Platforms>
<PublishProfile>win10-$(Platform).pubxml</PublishProfile>
</PropertyGroup>
<ItemGroup>
<AppxManifest Include="Package.appxmanifest">
<SubType>Designer</SubType>
</AppxManifest>
</ItemGroup>
<ItemGroup>
<PackageReference Include="Microsoft.WindowsAppSDK" Version="1.1.0" />
<PackageReference Include="Microsoft.Graphics.Win2D" Version="1.0.0.30"
/>
<PackageReference
Include="Microsoft.DotNet.UpgradeAssistant.Extensions.Default.Analyzers"
Version="0.4.346201">
<PrivateAssets>all</PrivateAssets>
</PackageReference>
<PackageReference Include="Microsoft.Windows.Compatibility"
Version="6.0.0" />
<PackageReference Include="CommunityToolkit.WinUI.UI.Animations"
Version="7.1.2" />
</ItemGroup>
<ItemGroup>
<Compile Remove="App.xaml.old.cs" />
</ItemGroup>
<ItemGroup>
<None Include="App.xaml.old.cs" />
</ItemGroup>
</Project>

Comme vous pouvez le voir, le projet référence maintenant le SDK d’application

Windows, WinUI 3 et .NET 6. Maintenant que PhotoLab a été migré, vous pouvez tirer
parti de toutes les nouvelles fonctionnalités offertes par les applications WinUI 3 et
développer votre application avec la plateforme.

Par ailleurs, l’Assistant Mise à niveau .NET ajoute des analyseurs au projet pour aider à
poursuivre le processus de mise à niveau. Par exemple, le package NuGet
Microsoft.DotNet.UpgradeAssistant.Extensions.Default.Analyzers.

Suivi de la migration manuelle

À ce stade, vous pouvez ouvrir la solution ou le projet PhotoLab migré et voir les
changements qui ont été effectués dans le code source. Le projet a besoin d’un peu plus
de travail pour finir de tout raccorder avant que la version WinUI 3 soit générée,
s’exécute et se comporte comme la version UWP.

Consultez la Liste des tâches dans Visual Studio (Afficher>Liste des tâches) afin de
connaître les éléments TODO que vous devez actionner pour terminer manuellement la
migration.

Il est possible que la version UWP (.NET Framework) de votre application contienne des
références de bibliothèque que votre projet n’utilise pas. Vous devez analyser chaque
référence et déterminer si elle est nécessaire ou non. L’outil a peut-être aussi ajouté ou
mis à niveau une référence de package NuGet vers la mauvaise version.

L’Assistant Mise à niveau ne modifie pas le Package.appxmanifest , qui nécessite des

modifications pour lancer l’application :

1. Ajoutez cet espace de noms à l’élément <Package> racine :

xmlns:rescap="http://schemas.microsoft.com/appx/manifest/foundation/windows1
0/restrictedcapabilities"

2. Modifiez l’élément <Application> de EntryPoint="appnamehere.App" vers

EntryPoint="$targetentrypoint$"

3. Remplacez toute Capability spécifiée par ceci :

XML

<rescap:Capability Name="runFullTrust" />

Dans votre fichier .csproj , vous devez peut-être modifier le fichier projet pour définir
<OutputType>WinExe</OutputType> et <UseMaui>False</UseMaui> .

Pour utiliser un grand nombre de contrôles XAML, vérifiez que votre fichier app.xaml
contient <XamlControlsResources> , comme dans cet exemple :

XML

<Application.Resources>
<ResourceDictionary>
<ResourceDictionary.MergedDictionaries>
<XamlControlsResources xmlns="using:Microsoft.UI.Xaml.Controls"
/>
<!-- Other merged dictionaries here -->
 </ResourceDictionary.MergedDictionaries>
<!-- Other app resources here -->
</ResourceDictionary>
</Application.Resources>

Conseils de dépannage
Plusieurs problèmes connus peuvent se produire lors de l’utilisation de l’Assistant Mise à
niveau de .NET. Dans certains cas, il s’agit de problèmes avec l’outil try-convert que
l’Assistant Mise à niveau de .NET utilise en interne.

Toutefois, pour d’autres conseils de résolution de problèmes et problèmes connus,

consultez le dépôt GitHub de l’Assistant Mise à niveau .
Mettre à niveau un projet côté serveur
WCF vers CoreWCF
Article • 31/10/2024

L’Assistant Mise à niveau .NET est un outil de ligne de commande qui aide à mettre à
niveau un projet WCF côté serveur existant sur .NET Framework afin d’utiliser les services
CoreWCF sur .NET 6. Cet article fournit :

Ce qu’il faut savoir avant de commencer.

Une démonstration de la façon d’exécuter l’outil sur un projet côté serveur WCF
sur .NET Framework.
Conseils en matière de résolution des problèmes.

Ce qu’il faut savoir avant de commencer

Cet outil prend actuellement en charge les projets C# et utilise CoreWCF pour porter
des projets WCF auto-hébergés côté serveur vers .NET 6.

） Important

La mise à niveau des projets WCF nécessite une version héritée de l’Assistant Mise
à niveau .NET et n’est pas compatible avec les dernières versions. Des instructions
sur l’installation de la version héritée sont fournies dans la section Installer la
version héritée.

Pour qu’un projet WCF soit applicable à cette mise à niveau, il doit répondre aux
exigences suivantes :

1. Inclut un fichier .cs qui référence System.ServiceModel et crée un nouveau

ServiceHost .

Si le projet WCF a plusieurs ServiceHost , tous les hôtes doivent être créés dans la
même méthode.

2. Inclut un fichier .config qui stocke les propriétés System.ServiceModel .

La version actuelle de l’outil ne prend pas en charge les projets WCF hébergés via des
fichiers .svc.

７ Notes
 Si votre projet n’est pas applicable pour cet outil, nous vous recommandons de
consulter le Guide de procédure pas à pas CoreWCF et l’exemple de
démonstration BeanTrader et de mettre à jour manuellement le projet.

Prérequis
Système d'exploitation Windows
Visual Studio 2022 version 17.1 ou ultérieure .
Kit sdk .NET 6 ou version ultérieure .
Version 0.4.421302 de l’Assistant Mise à niveau .NET, appelée version « héritée ».

Installer la version héritée

Utilisez la commande pour installer la dotnet version 0.4.421302 de l’Assistant Mise à
niveau .NET.

CLI .NET

dotnet tool install upgrade-assistant -g --version 0.4.421302

） Important

Si vous avez configuré des sources de flux NuGet supplémentaires, l’installation

peut échouer avec une erreur indiquant que le package NuGet n’est pas disponible
dans le flux. Utilisez le --ignore-failed-sources paramètre pour traiter ces échecs
comme des avertissements au lieu d’erreurs, en contournant les autres sources de
flux NuGet :

CLI .NET

dotnet tool install upgrade-assistant -g --ignore-failed-sources --

version 0.4.421302

Application de démonstration
Vous pouvez utiliser l’exemple de projet Calculatrice de base pour tester la mise à
niveau avec l’Assistant Mise à niveau, qui est également la démonstration utilisée dans
cette documentation.
Si vous voulez essayer un exemple plus complexe, consultez l’exemple BeanTrader
créé par Mike Rousos.

Exécuter l’Assistant Mise à niveau

Ouvrez un terminal et accédez au dossier où se trouve le projet ou la solution cible.
Exécutez la commande upgrade-assistant upgrade en passant le nom du projet ou de la
solution que vous mettez à niveau.

Quand un projet est spécifié, le processus de mise à niveau démarre immédiatement sur
ce projet. Si une solution est fournie, vous sélectionnez le projet que vous exécutez
normalement, appelé « point d’entrée de mise à niveau ». Basé sur ce projet, un
graphique des dépendances est créé et une suggestion sur l’ordre dans lequel vous
devez mettre à niveau les projets est fournie.

Console

upgrade-assistant upgrade .\CalculatorSample.sln

L’outil s’exécute et vous montre une liste des étapes qu’il va effectuer. À mesure que
chaque étape est effectuée, l’outil fournit un ensemble de commandes permettant à
l’utilisateur d’appliquer ou d’ignorer l’étape suivante ou une autre option, comme par
exemple :

Obtenir plus d’informations sur l’étape.

Changer les projets.
Ajuster les paramètres de journalisation.
Arrêter la mise à niveau et quitter.

Si vous appuyez sur Entrée sans choisir un numéro, c’est le premier élément de la liste
qui est sélectionné.

À mesure que chaque étape s’initialise, elle peut fournir des informations sur ce qui peut
se produire si vous appliquez l’étape.

Sélectionner le point d’entrée et le projet à mettre à

niveau
La première étape de la mise à niveau de l’exemple de calculatrice de base consiste à
choisir le projet dans la solution qui sert de projet de point d’entrée.

Output
 Upgrade Steps

1. [Next step] Select an entrypoint

2. Select project to upgrade

Choose a command:
1. Apply next step (Select an entrypoint)
2. Skip next step (Select an entrypoint)
3. See more step details
4. Configure logging
5. Exit

Choisissez la commande 1 pour démarrer cette étape. Les résultats sont affichés :

Output

[10:25:42 INF] Applying upgrade step Select an entrypoint

Please select the project you run. We will then analyze the dependencies and
identify the recommended order to upgrade projects.
1. CalculatorClient
2. CalculatorService

Deux projets sont listés. Comme notre outil met à niveau le projet côté serveur, nous
allons choisir la commande 2 pour sélectionner le projet de service comme point
d’entrée.

Mettre à niveau le projet

Une fois qu’un projet est sélectionné, une liste des étapes de mise à niveau qui seront
effectuées par l’outil est affichée.

） Important

En fonction du projet que vous mettez à niveau, vous pouvez ou non voir toutes les
étapes listées dans cet exemple.

La sortie suivante décrit les étapes impliquées dans la mise à niveau du projet :

Output

Upgrade Steps

Entrypoint:
C:\Users\Desktop\CalculatorSample\CalculatorService\CalculatorService.csproj
Current Project:
C:\Users\Desktop\CalculatorSample\CalculatorService\CalculatorService.csproj

1. [Next step] Back up project

2. Convert project file to SDK style
3. Clean up NuGet package references
a. Duplicate reference analyzer
b. Package map reference analyzer
c. Target compatibility reference analyzer
d. Upgrade assistant reference analyzer
e. Windows Compatibility Pack Analyzer
f. MyDotAnalyzer reference analyzer
g. Newtonsoft.Json reference analyzer
h. Windows App SDK package analysis
i. Transitive reference analyzer
4. Update TFM
5. Update NuGet Packages
a. Duplicate reference analyzer
b. Package map reference analyzer
c. Target compatibility reference analyzer
d. Upgrade assistant reference analyzer
e. Windows Compatibility Pack Analyzer
f. MyDotAnalyzer reference analyzer
g. Newtonsoft.Json reference analyzer
h. Windows App SDK package analysis
i. Transitive reference analyzer
6. Add template files
7. Update WCF service to CoreWCF (Preview)
8. Upgrade app config files
a. Convert Application Settings
b. Convert Connection Strings
c. Disable unsupported configuration sections
9. Update source code
a. Apply fix for UA0002: Types should be upgraded
b. Apply fix for UA0012: 'UnsafeDeserialize()' does not exist
c. Apply fix for UA0014: .NET MAUI projects should not reference
Xamarin.Forms namespaces
d. Apply fix for UA0015: .NET MAUI projects should not reference
Xamarin.Essentials namespaces
10. Move to next project

Choose a command:
1. Apply next step (Back up project)
2. Skip next step (Back up project)
3. See more step details
4. Select different project
5. Configure logging
6. Exit

７ Notes

Pour le reste de cet article, les étapes de mise à niveau ne sont pas montrées
explicitement, sauf s’il y a quelque chose d’important à signaler. Les résultats de
 chaque étape sont néanmoins toujours affichés.

Création d'une sauvegarde

Dans cet exemple de mise à niveau du projet CalculatorService, vous allez appliquer
chaque étape. La première étape, commande 1, consiste à sauvegarder le projet :

Output

[10:25:52 INF] Applying upgrade step Back up project

Please choose a backup path
1. Use default path [C:\Users\Desktop\CalculatorSample.backup]
2. Enter custom path

L’outil choisit un chemin de sauvegarde par défaut nommé d’après le dossier actif, mais
y ajoute .backup . Vous pouvez choisir un chemin personnalisé comme alternative au
chemin par défaut. Pour chaque projet mis à niveau, le dossier du projet est copié dans
le dossier de sauvegarde. Dans cet exemple, le dossier CalculatorService est copié
depuis CalculatorSample\CalculatorService vers
CalculatorSample.backup\CalculatorService pendant l’étape de sauvegarde :

Output

[10:25:53 INF] Backing up

C:\Users\Desktop\CalculatorSample\CalculatorService to C:\Users\OneDrive -
Microsoft\Desktop\CalculatorSample.backup\CalculatorService
[10:25:53 INF] Project backed up to
C:\Users\Desktop\CalculatorSample.backup\CalculatorService
[10:25:53 INF] Upgrade step Back up project applied successfully
Please press enter to continue...

Mettre à niveau le fichier projet

Le projet est mis à niveau du format de projet .NET Framework vers le format de projet
SDK .NET.

Output

[10:25:56 INF] Applying upgrade step Convert project file to SDK style
[10:25:56 INF] Converting project file format with try-convert, version
0.4.0-dev
[10:25:56 INF] Recommending executable TFM net6.0 because the project builds
to an executable
C:\Users\Desktop\CalculatorSample\CalculatorService\CalculatorService.csproj
contains an App.config file. App.config is replaced by appsettings.json in
 .NET Core. You will need to delete App.config and migrate to
appsettings.json if it's applicable to your project.
[10:25:58 INF] Converting project
C:\Users\CalculatorSample\CalculatorService\CalculatorService.csproj to SDK
style
[10:25:58 INF] Project file converted successfully! The project may require
additional changes to build successfully against the new .NET target.
[10:26:00 INF] Upgrade step Convert project file to SDK style applied
successfully

Faites attention à la sortie de chaque étape. Notez que l’exemple de sortie indique que
vous devrez effectuer une étape manuelle après la mise à niveau :

App.config est remplacé par appsettings.json dans .NET Core. Vous devrez
supprimer App.config et migrer vers appsettings.json si c’est applicable à votre
projet.

Dans cet exemple, l’étape de mise à jour WCF va créer un fichier wcf.config basé sur la
section system.serviceModel de App.config. Nous n’avons pas besoin de migrer vers
appsettings.json.

Nettoyer les références NuGet

Une fois que le format du projet a été mis à jour, l’étape suivante consiste à nettoyer les
références du package NuGet.

En plus des packages référencés par votre application, le fichier packages.config contient
des références aux dépendances de ces packages. Par exemple, si vous avez ajouté une
référence au package A qui dépend du package B, les deux packages sont référencés
dans le fichier packages.config. Dans le nouveau système de projet, seule la référence au
package A est nécessaire. Cette étape analyse les références de package et supprime
celles qui ne sont pas nécessaires.

Output

[10:26:01 INF] Initializing upgrade step Clean up NuGet package references

[10:26:01 INF] Initializing upgrade step Duplicate reference analyzer
[10:26:01 INF] No package updates needed
[10:26:01 INF] Initializing upgrade step Package map reference analyzer
[10:26:01 INF] Marking assembly reference System.configuration for removal
based on package mapping configuration System.Configuration
[10:26:01 INF] Adding package System.Configuration.ConfigurationManager
based on package mapping configuration System.Configuration
[10:26:01 INF] Marking assembly reference System.ServiceModel for removal
based on package mapping configuration System.ServiceModel
[10:26:01 INF] Adding package System.ServiceModel.Primitives based on
package mapping configuration System.ServiceModel
[10:26:01 INF] Adding package System.ServiceModel.Http based on package
mapping configuration System.ServiceModel
[10:26:01 INF] Adding package System.ServiceModel.Duplex based on package
mapping configuration System.ServiceModel
[10:26:01 INF] Adding package System.ServiceModel.NetTcp based on package
mapping configuration System.ServiceModel
[10:26:01 INF] Adding package System.ServiceModel.Security based on package
mapping configuration System.ServiceModel
[10:26:01 INF] Adding package System.ServiceModel.Federation based on
package mapping configuration System.ServiceModel

[10:26:01 INF] Initializing upgrade step Remove reference

'System.configuration'
[10:26:03 INF] Applying upgrade step Remove reference 'System.configuration'
[10:26:03 INF] Removing outdated assembly reference: System.configuration
[10:26:03 INF] Upgrade step Remove reference 'System.configuration' applied
successfully

[10:26:05 INF] Initializing upgrade step Remove reference

'System.ServiceModel'
[10:26:06 INF] Applying upgrade step Remove reference 'System.ServiceModel'
[10:26:06 INF] Removing outdated assembly reference: System.ServiceModel
[10:26:06 INF] Upgrade step Remove reference 'System.ServiceModel' applied
successfully

[10:26:07 INF] Initializing upgrade step Add package

'System.Configuration.ConfigurationManager'
[10:26:09 INF] Applying upgrade step Add package
'System.Configuration.ConfigurationManager'
[10:26:09 INF] Adding package reference:
System.Configuration.ConfigurationManager, Version=5.0.0
[10:26:09 INF] Upgrade step Add package
'System.Configuration.ConfigurationManager' applied successfully
[10:26:09 INF] Applying upgrade step Package map reference analyzer
[10:26:09 INF] Upgrade step Package map reference analyzer applied
successfully

[10:26:10 INF] Initializing upgrade step Target compatibility reference

analyzer
[10:26:10 INF] No package updates needed
[10:26:10 INF] Initializing upgrade step Upgrade assistant reference
analyzer
[10:26:11 INF] Reference to .NET Upgrade Assistant analyzer package
(Microsoft.DotNet.UpgradeAssistant.Extensions.Default.Analyzers, version
0.4.336902) needs to be added
[10:26:11 INF] Initializing upgrade step Add package
'Microsoft.DotNet.UpgradeAssistant.Extensions.Default.Analyzers'
[10:26:13 INF] Applying upgrade step Add package
'Microsoft.DotNet.UpgradeAssistant.Extensions.Default.Analyzers'
[10:26:13 INF] Adding package reference:
Microsoft.DotNet.UpgradeAssistant.Extensions.Default.Analyzers,
Version=0.4.336902
[10:26:13 INF] Upgrade step Add package
'Microsoft.DotNet.UpgradeAssistant.Extensions.Default.Analyzers' applied
 successfully
[10:26:13 INF] Applying upgrade step Upgrade assistant reference analyzer
[10:26:14 INF] Upgrade step Upgrade assistant reference analyzer applied
successfully

[10:26:15 INF] Initializing upgrade step Windows Compatibility Pack Analyzer

[10:26:15 INF] No package updates needed
[10:26:15 INF] Initializing upgrade step MyDotAnalyzer reference analyzer
[10:26:15 INF] No package updates needed
[10:26:15 INF] Initializing upgrade step Newtonsoft.Json reference analyzer
[10:26:15 INF] No package updates needed
[10:26:15 INF] Initializing upgrade step Windows App SDK package analysis
[10:26:15 INF] No package updates needed
[10:26:15 INF] Initializing upgrade step Transitive reference analyzer
[10:26:15 INF] No package updates needed
[10:26:15 INF] Applying upgrade step Clean up NuGet package references
[10:26:15 INF] Upgrade step Clean up NuGet package references applied
successfully

Votre application fait néanmoins toujours référence aux assemblys .NET Framework.
Certains de ces assemblys peuvent être disponibles en tant que packages NuGet. Cette
étape analyse ces assemblys et référence le package NuGet approprié.

Dans cet exemple, le programme de mise à jour de package détecte CalculatorService

en tant que projet serveur uniquement et il n’est pas nécessaire d’ajouter des packages
System.ServiceModel . Même si elles ont été ajoutées à la liste en fonction de la

configuration du mappage des packages, ces étapes n’ont pas été appliquées.

Gérer le TFM
L’outil change ensuite le TFM et le fait passer de .NET Framework au SDK suggéré. Dans
cet exemple, il s’agit de net6.0-windows .

Output

[10:26:17 INF] Applying upgrade step Update TFM

[10:26:17 INF] Recommending executable TFM net6.0 because the project builds
to an executable
[10:26:19 INF] Updated TFM to net6.0
[10:26:19 INF] Upgrade step Update TFM applied successfully

Mettre à niveau des packages NuGet

Ensuite, l’outil met à jour les packages NuGet du projet vers les versions qui prennent en
charge le TFM mis à jour, net6.0-windows .
 Output

[10:26:20 INF] Initializing upgrade step Update NuGet Packages

[10:26:20 INF] Initializing upgrade step Duplicate reference analyzer
[10:26:20 INF] No package updates needed
[10:26:20 INF] Initializing upgrade step Package map reference analyzer
[10:26:20 INF] No package updates needed
[10:26:20 INF] Initializing upgrade step Target compatibility reference
analyzer
[10:26:20 INF] No package updates needed
[10:26:20 INF] Initializing upgrade step Upgrade assistant reference
analyzer
[10:26:20 INF] No package updates needed
[10:26:20 INF] Initializing upgrade step Windows Compatibility Pack Analyzer
[10:26:20 INF] No package updates needed
[10:26:20 INF] Initializing upgrade step MyDotAnalyzer reference analyzer
[10:26:20 INF] No package updates needed
[10:26:20 INF] Initializing upgrade step Newtonsoft.Json reference analyzer
[10:26:20 INF] No package updates needed
[10:26:20 INF] Initializing upgrade step Windows App SDK package analysis
[10:26:20 INF] No package updates needed
[10:26:20 INF] Initializing upgrade step Transitive reference analyzer
[10:26:20 INF] No package updates needed
[10:26:20 INF] Applying upgrade step Update NuGet Packages
[10:26:20 INF] Upgrade step Update NuGet Packages applied successfully

Ajouter des fichiers modèles

Une fois les packages mis à jour, l’étape suivante consiste à mettre à jour les fichiers
modèles. Dans cet exemple, aucun fichier modèle ne doit être mis à jour ou ajouté au
projet. Cette étape est ignorée et l’étape suivante démarre automatiquement.

Output

[10:26:20 INF] Initializing upgrade step Add template files

[10:26:20 INF] 0 expected template items needed

Mettre à jour le service WCF vers CoreWCF (préversion)

Remarque : Au moment de la rédaction de cette documentation, l’extension du

programme de mise à jour WCF est fournie en tant que préversion. Si vous avez un
feedback sur la préversion, ouvrez un problème dans le dépôt GitHub de l’Assistant
Mise à niveau avec l’étiquette area:WCF .

L’Assistant Mise à niveau initialise d’abord l’étape Programme de mise à jour WCF et
vérifie si le projet est applicable pour la mise à jour WCF.
 Output

[10:26:20 INF] Initializing upgrade step Update WCF service to CoreWCF

(Preview)
[10:26:20 INF] This config file is applicable for upgrade:
C:\Users\Desktop\CalculatorSample\CalculatorService\App.config.
System.serviceModel/services elements were found.
[10:26:20 INF] This file is applicable for upgrade:
C:\Users\Desktop\CalculatorSample\CalculatorService\service.cs. ServiceHost
object was found.
[10:26:20 INF] This project file is applicable for upgrade:
C:\Users\Desktop\CalculatorSample\CalculatorService\CalculatorService.csproj
. Reference to System.serviceModel was found.
[10:26:20 INF] This project is applicable for updating to CoreWCF.
Initializing the update step...
[10:26:20 INF] Updaters are successfully constructed. Ready to start update.

Choose a command:
1. Apply next step (Update WCF service to CoreWCF (Preview))
2. Skip next step (Update WCF service to CoreWCF (Preview))
3. See more step details
4. Select different project
5. Configure logging
6. Exit

L’étape vérifie le fichier de configuration, le code source et le fichier projet séparément

pour déterminer si la mise à jour WCF est applicable au projet. Si ce n’est pas applicable
pour le projet (par exemple si vous n’utilisez pas WCF ou que ne satisfaites pas aux
exigences énoncées au début de l’article), le message de journalisation décrit le fichier
pour lequel ce n’est pas applicable et ce qui est manquant. Ensuite, l’étape est ignorée
et l’étape suivante est démarrée automatiquement.

Dans cet exemple, la mise à jour WCF est applicable pour CalculatorSample et nous
allons choisir la commande 1 pour appliquer l’étape.

Output

[10:26:23 INF] Applying upgrade step Update WCF service to CoreWCF (Preview)
[10:26:23 INF] Finish updating project file.
[10:26:23 WRN] The mex endpoint is removed from .config file, and service
metadata behavior is configured in the source code instead.
[10:26:23 INF] Finish updating configuration files.
[10:26:23 WRN] Changing void Main() to async Task Main() to enable awaiting
starting and stopping the ASP.NET Core host.
[10:26:23 INF] Finish updating source code.
[10:26:23 INF] Finish writing changes to project file.
[10:26:23 INF] Finish writing changes to configuration files.
[10:26:23 INF] Finish writing changes to the source code to replace the
ServiceHost instance(s).
[10:26:23 INF] Project was successfully updated to use CoreWCF services.
 Please review changes.
[10:26:23 INF] Upgrade step Update WCF service to CoreWCF (Preview) applied
successfully

Cette étape crée les mises à jour et les écrit individuellement dans les fichiers d’origine.
Faites attention à la sortie, qui peut vous avertir de la suppression des fichiers d’origine
ou des mises à jour manuelles à effectuer après la mise à niveau.

Mise à jour des fichiers de configuration et de code

Ces étapes peuvent être ignorées automatiquement par l’outil s’il détermine qu’il n’y a
rien à faire pour votre projet.

Une fois la mise à jour WCF terminée, l’étape suivante consiste à mettre à jour les
fichiers de configuration de l’application. Dans cet exemple, il n’y a rien à mettre à
niveau dans les fichiers de configuration de l’application. L’étape WCF a déjà mis à jour
les fichiers de configuration : cette étape ne signale donc rien sur l’utilisation du
system.serviceModel non pris en charge. Cette étape est ignorée et l’étape suivante

démarre automatiquement.

Output

[10:26:43 INF] Initializing upgrade step Upgrade app config files

[10:26:43 INF] Found 0 app settings for upgrade:
[10:26:43 INF] Found 0 connection strings for upgrade:
[10:26:43 INF] 0 web page namespace imports need upgraded:

La dernière étape avant la fin de la mise à niveau de ce projet consiste à mettre à jour
toutes les références de code obsolètes. En fonction du type de projet que vous mettez
à niveau, une liste de correctifs de code connus est affichée pour cette étape. Certains
des correctifs peuvent ne pas s’appliquer à votre projet.

Output

9. Update source code

a. Apply fix for UA0002: Types should be upgraded
b. Apply fix for UA0012: 'UnsafeDeserialize()' does not exist
c. Apply fix for UA0014: .NET MAUI projects should not reference
Xamarin.Forms namespaces
d. Apply fix for UA0015: .NET MAUI projects should not reference
Xamarin.Essentials namespaces

Dans le cas présent, aucun des correctifs suggérés ne s’applique à l’exemple de projet,
et cette étape se termine automatiquement immédiatement après la fin de l’étape
précédente.

Output

[10:26:44 INF] Initializing upgrade step Update source code

[10:26:44 INF] Running analyzers on CalculatorService
[10:26:48 INF] Identified 0 diagnostics in project CalculatorService
[10:26:51 INF] Initializing upgrade step Move to next project

Réalisation de la mise à niveau

S’il existe d’autres projets à migrer, l’outil vous permet de sélectionner le projet suivant à
mettre à niveau. Quand il n’y a plus de projets à mettre à niveau, l’outil vous amène à
l’étape « Finaliser la mise à niveau » :

Output

1. [Next step] Finalize upgrade

Choose a command:
1. Apply next step (Finalize upgrade)
2. Skip next step (Finalize upgrade)
3. See more step details
4. Configure logging
5. Exit
>
[10:27:15 INF] Applying upgrade step Finalize upgrade
[10:27:15 INF] Upgrade step Finalize upgrade applied successfully

Dans l’idéal, après la réussite de l’exécution de l’outil, ces modifications doivent

apparaître dans les fichiers d’origine.

Dans le fichier service.cs , le using System.ServiceModel a été remplacé par des

références à CoreWCF. L’instance ServiceHost a également été supprimée et le service a
été hébergé sur ASP.NET Core.

C#

using System;
using System.Threading.Tasks;
using CoreWCF;
using CoreWCF.Configuration;
using CoreWCF.Description;
using CoreWCF.Security;
using Microsoft.AspNetCore.Builder;
using Microsoft.AspNetCore.Hosting;
using Microsoft.Extensions.DependencyInjection;
C#

public static async Task Main()

{
var builder = WebApplication.CreateBuilder();

// Set up port (previously this was done in configuration,

// but CoreWCF requires it be done in code)
builder.WebHost.UseNetTcp(8090);
builder.WebHost.ConfigureKestrel(options =>
{
options.ListenAnyIP(8080);
});

// Add CoreWCF services to the ASP.NET Core app's DI container

builder.Services.AddServiceModelServices()

.AddServiceModelConfigurationManagerFile("wcf.config")
.AddServiceModelMetadata()
.AddTransient<CalculatorSample.CalculatorService>();

var app = builder.Build();

// Enable getting metadata/wsdl

var serviceMetadataBehavior =
app.Services.GetRequiredService<ServiceMetadataBehavior>();
serviceMetadataBehavior.HttpGetEnabled = true;
serviceMetadataBehavior.HttpGetUrl = new
Uri("http://localhost:8080/CalculatorSample/metadata");

// Configure CoreWCF endpoints in the ASP.NET Core hosts

app.UseServiceModel(serviceBuilder =>
{
serviceBuilder.AddService<CalculatorSample.CalculatorService>
(serviceOptions =>
{
serviceOptions.DebugBehavior.IncludeExceptionDetailInFaults
= true;
});

serviceBuilder.ConfigureServiceHostBase<CalculatorSample.CalculatorService>
(serviceHost =>
{

});
});

await app.StartAsync();
Console.WriteLine("The service is ready.");
Console.WriteLine("Press <ENTER> to terminate service.");
Console.WriteLine();
Console.ReadLine();
 await app.StopAsync();
}

Pour les fichiers de configuration, la section system.serviceModel dans App.config a été

déplacée vers le nouveau fichier de configuration wcf.config , qui a été généré pendant
la mise à jour.

App.config

XML

<?xml version="1.0" encoding="utf-8"?>

<configuration>
<!-- system.serviceModel section is moved to a separate wcf.config file
located at the same directory as this file.-->
</configuration>

wcf.config

XML

<?xml version="1.0" encoding="utf-8"?>

<configuration>
<system.serviceModel>
<services>
<service name="CalculatorSample.CalculatorService"
behaviorConfiguration="CalculatorServiceBehavior">
<!--The host element is not supported in configuration in CoreWCF.
The port that endpoints listen on is instead configured in the source code.-
->
<!--<host>
<baseAddresses>
<add baseAddress="net.tcp://localhost:8090/CalculatorSample/service" />
<add baseAddress="http://localhost:8080/CalculatorSample/service" />
</baseAddresses>
</host>-->
<!-- this endpoint is exposed at the base address provided by host:
net.tcp://localhost:8090/CalculatorSample/service -->
<endpoint address="/CalculatorSample/service"
binding="netTcpBinding" contract="CalculatorSample.ICalculator" />
<!-- the mex endpoint is exposed at
http://localhost:8080/CalculatorSample/service/ -->
<!--The mex endpoint is removed because it's not support in CoreWCF.
Instead, the metadata service is enabled in the source code.-->
</service>
</services>
<!--For debugging purposes set the includeExceptionDetailInFaults
attribute to true-->
<!--The behavior element is not supported in configuration in CoreWCF.
Some service behaviors, such as metadata, are configured in the source
 code.-->
<!--<behaviors>
<serviceBehaviors>
<behavior name="CalculatorServiceBehavior">
<serviceMetadata httpGetEnabled="True" />
<serviceDebug includeExceptionDetailInFaults="True" />
</behavior>
</serviceBehaviors>
</behaviors>-->
</system.serviceModel>
</configuration>

Enfin, dans le fichier projet, CalculatorService.csproj , le SDK a été mis à jour vers
Microsoft.NET.Sdk.Web pour activer l’hôte ASP.NET Core et les références de package

CoreWCF ont été ajoutées.

XML

<ItemGroup>
<PackageReference Include="System.Configuration.ConfigurationManager"
Version="5.0.0" />
<PackageReference
Include="Microsoft.DotNet.UpgradeAssistant.Extensions.Default.Analyzers"
Version="0.4.336902">
<PrivateAssets>all</PrivateAssets>
</PackageReference>
<PackageReference Include="CoreWCF.NetTcp" Version="1.1.0" />
<PackageReference Include="CoreWCF.Primitives" Version="1.1.0" />
<PackageReference Include="CoreWCF.ConfigurationManager" Version="1.1.0"
/>
<PackageReference Include="CoreWCF.Http" Version="1.1.0" />
<PackageReference Include="CoreWCF.WebHttp" Version="1.1.0" />
</ItemGroup>

Notez que dans CalculatorSample, il n’existe pas de dépendance de projet à projet et

que l’exemple peut s’exécuter correctement seulement après la mise à jour de
CalculatorService. Dans d’autres cas avec des dépendances différentes, vous devrez
néanmoins peut-être aussi mettre à jour d’autres projets de la même solution.

Après la mise à niveau

Après avoir mis à niveau vos projets, vous devez les compiler et les tester. L’Assistant
Mise à niveau va faire ce qu’il peut, mais il ne peut pas résoudre toutes les
incompatibilités dans le cadre de la mise à niveau du projet. Par exemple, il est possible
que la version .NET Framework de votre application contienne des références de
bibliothèque que votre projet n’utilise pas. Vous devez analyser chaque référence et
déterminer si elle est nécessaire ou non. L’outil a peut-être aussi ajouté ou mis à niveau
une référence de package NuGet vers une version incorrecte.

Conseils de dépannage
Plusieurs problèmes connus peuvent se produire lors de l’utilisation de l’Assistant Mise à
niveau de .NET. Dans certains cas, il s’agit de problèmes avec l’outil try-convert que
l’Assistant Mise à niveau de .NET utilise en interne.

Le référentiel GitHub de l’outil a des conseils de dépannage et des problèmes connus.

Voir aussi
Blog : Mise à niveau d’un service WCF vers .NET 6 avec CoreWCF
Blog : CoreWCF 1.0 a été publié, WCF pour .NET Core et .NET 5+
Documentations : Vue d’ensemble de l’Assistant Mise à niveau de .NET
Télémétrie de l’Assistant Mise à niveau
Article • 22/05/2023

L’Assistant Mise à niveau inclut une fonctionnalité de télémétrie qui collecte des
données d’utilisation. Les données de télémétrie sont utilisées pour aider à comprendre
comment apporter des améliorations à l’outil.

Comment désactiver la fonctionnalité

La fonctionnalité de télémétrie de l’Assistant Mise à niveau est activée par défaut. Pour
désactiver la fonctionnalité de télémétrie, définissez la variable d’environnement
DOTNET_UPGRADEASSISTANT_TELEMETRY_OPTOUT sur 1 ou true .

Console

Créez et assignez une variable d’environnement persistante, en fonction de la valeur

donnée.

Console

:: Assigns the env var to the value

setx DOTNET_UPGRADEASSISTANT_TELEMETRY_OPTOUT="1"

Dans une nouvelle instance de l’invite de commandes, lisez la variable

d’environnement.

Console

:: Prints the env var value

echo %DOTNET_UPGRADEASSISTANT_TELEMETRY_OPTOUT%

Divulgation d’informations
L’Assistant Mise à niveau affiche un texte similaire à ce qui suit lorsque vous exécutez
l’outil pour la première fois. Le texte peut varier légèrement selon la version de l’outil
que vous exécutez. Lors de cette première exécution, Microsoft vous informe sur la
collecte de données.

Console
 Telemetry

Upgrade Assistant collects usage data in order to help us improve your

experience. The data is collected by Microsoft and shared with the
community. You can opt-out of telemetry by setting the
DOTNET_UPGRADEASSISTANT_TELEMETRY_OPTOUT environment variable to '1' or
'true' using your favorite shell.

Pour supprimer le texte de l’expérience « première exécution », définissez la variable

d’environnement DOTNET_UPGRADEASSISTANT_SKIP_FIRST_TIME_EXPERIENCE sur 1 ou true .

Points de données
La fonctionnalité de télémétrie n’effectue pas les actions suivantes :

Collecter des exemples de code

Les données sont envoyées en toute sécurité aux serveurs Microsoft et conservées sous
un accès restreint.

Nous prenons la protection de vos données au sérieux. Si vous pensez que la

fonctionnalité de télémétrie collecte des données sensibles ou que les données sont
gérées de manière non sécurisée ou inappropriée, effectuez l’une des actions suivantes :

Enregistrer un problème dans le référentiel dotnet/upgrade-assistant .

Envoyer un e-mail à [email protected] pour investigation.

La fonctionnalité de télémétrie collecte les données suivantes.

Versions de Données
l’Assistant Mise à
niveau

>=0.2.231802 Horodatage de l’appel.

>=0.2.231802 Adresse IP de trois octets utilisée pour déterminer l’emplacement

géographique.

>=0.2.231802 Système d’exploitation et version.

>=0.2.231802 ID du runtime (RID) sur lequel l’outil s’exécute.

>=0.2.231802 Si l’outil est en cours d’exécution dans un conteneur.

>=0.2.231802 Adresse MAC (Media Access Control) hachée : ID unique et haché

(SHA256) du point de vue du chiffrement pour une machine.
Versions de Données
l’Assistant Mise à
niveau

>=0.2.231802 Version du noyau.

>=0.2.231802 Versions de l’Assistant Mise à niveau.

>=0.2.231802 Noms des commandes et des arguments appelés. Les valeurs d’argument
réelles ne sont pas collectées.

>=0.2.231802 Version de MSBuild utilisée.

>=0.2.231802 ID de solution hachée (ou chemin haché si aucun ID n’est disponible).

>=0.2.231802 ID de projet haché (ou chemin haché si aucun ID n’est disponible) pour
chaque projet.

>=0.2.231802 ID de projet haché (ou chemin haché si aucun ID n’est disponible) pour
chaque point d’entrée.

>=0.2.231802 Pour chaque étape, temps d’initialisation et d’application de l’étape.

>=0.2.231802 Pour chaque étape, la décision sélectionnée (par exemple, apply ).

Ressources supplémentaires
Télémétrie du SDK .NET
Données de télémétrie de l’interface CLI .NET
Des changements cassants peuvent se
produire lors du portage du code
Article • 10/05/2023

Les modifications qui affectent la compatibilité, également appelées changements

cassants, se produisent entre les versions de .NET. Les modifications sont impactantes
lors du portage de .NET Framework vers .NET en raison de certaines technologies qui ne
sont pas disponibles. En outre, vous pouvez rencontrer des changements cassants
simplement parce que .NET est une technologie multiplateforme et .NET Framework ne
l’est pas.

Microsoft s’efforce de maintenir un niveau élevé de compatibilité entre les versions de

.NET. Donc, en cas de changement cassant, ils sont soigneusement pris en compte.

Avant de mettre à niveau les versions majeures, consultez la documentation sur les
changements cassants susceptibles de vous affecter.

Changements qui affectent la compatibilité

Il existe plusieurs types de modifications que les auteurs de bibliothèques peuvent
apporter et qui affectent la compatibilité, notamment :

Modifications au contrat public

Changements de comportement
Plateforme prise en charge
Modifications de l’implémentation interne
Modifications du code

Pour plus d’informations sur le type de modification autorisé ou interdit, consultez

Règles de modification pour la compatibilité.

Types de compatibilité
La compatibilité fait référence à la possibilité de compiler ou d’exécuter du code sur une
implémentation .NET autre que celle avec laquelle le code a été développé à l’origine.

Il existe six façons différentes d’affecter la compatibilité :

Changements de comportement
Compatibilité binaire
 Compatibilité source
Compatibilité au moment du design
Compatibilité descendante
Compatibilité ascendante

Pour plus d’informations, consultez Comment les modifications de code peuvent

affecter la compatibilité.

Rechercher les changements cassants

Les modifications qui affectent la compatibilité sont documentées. Passez en revue ces
modifications avant de porter votre code de .NET Framework vers .NET ou de le mettre à
niveau vers une version plus récente de .NET. Pour obtenir la liste de ces changements
cassants, consultez Changements cassants pour la migration de .NET Framework vers
.NET Core.
Changements de rupture pour la
migration de .NET Framework vers .NET
Core
Article • 02/01/2025

Si vous migrez une application de .NET Framework vers .NET Core versions 1.0 à 3.1, les
changements cassants répertoriés dans cet article peuvent vous affecter. Les
modifications de rupture sont regroupées par catégorie, et au sein de ces catégories,
par la version de .NET Core dans laquelle elles ont été introduites.

７ Notes

Cet article n’est pas une liste complète des changements cassants entre le .NET
Framework et .NET Core. Les changements majeurs les plus importants sont ajoutés
ici au fur et à mesure que nous les identifions.

Bibliothèques .NET Core

Changement de la valeur par défaut de UseShellExecute
API IDispatchImplAttribute est supprimée
UnauthorizedAccessException levé par FileSystemInfo.Attributes
La gestion des exceptions d’état de processus endommagés n’est pas prise en
charge
Les propriétés UriBuilder ne précèdent plus les caractères de début
Process.StartInfo lève une exception InvalidOperationException pour des processus
que vous n’avez pas démarrés

.NET 8
API IDispatchImplAttribute est supprimée

.NET Core 2.1

Modification de la valeur par défaut d’UseShellExecute

ProcessStartInfo.UseShellExecute a une valeur par défaut de false sur .NET Core. Sur
.NET Framework, sa valeur par défaut est true .

Description des modifications

Process.Start vous permet de lancer une application directement, par exemple, avec du
code tel que Process.Start("mspaint.exe") qui lance Paint. Il vous permet également
de lancer indirectement une application associée si ProcessStartInfo.UseShellExecute est
défini sur true . Sur .NET Framework, la valeur par défaut de
ProcessStartInfo.UseShellExecute est true , ce qui signifie que ce code tel que
Process.Start("mytextfile.txt") lance le Bloc-notes, si vous avez associé des fichiers

.txt à cet éditeur. Pour empêcher indirectement le lancement d’une application sur .NET
Framework, vous devez définir explicitement ProcessStartInfo.UseShellExecute sur
false . Sur .NET Core, la valeur par défaut de ProcessStartInfo.UseShellExecute est

false . Cela signifie que, par défaut, les applications associées ne sont pas lancées

lorsque vous appelez Process.Start .

Les propriétés suivantes sur System.Diagnostics.ProcessStartInfo ne sont fonctionnelles

que lorsque ProcessStartInfo.UseShellExecute est true :

ProcessStartInfo.CreateNoWindow
ProcessStartInfo.ErrorDialog
ProcessStartInfo.Verb
ProcessStartInfo.WindowStyle.

Cette modification a été introduite dans .NET Core pour des raisons de performances.
En règle générale, Process.Start est utilisé pour lancer une application directement. Le
lancement d’une application directement n’a pas besoin d’impliquer l’interpréteur de
commandes Windows et d’entraîner le coût de performances associé. Pour accélérer ce
cas par défaut, .NET Core modifie la valeur par défaut de
ProcessStartInfo.UseShellExecute en false . Vous pouvez opter pour le chemin lent si
vous en avez besoin.

Version introduite
2.1

７ Notes
 Dans les versions antérieures de .NET Core, UseShellExecute n’a pas été
implémenté pour Windows.

Action recommandée

Si votre application s’appuie sur l’ancien comportement, utilisez la fonction

Process.Start(ProcessStartInfo) avec UseShellExecute réglé à true sur l’objet
ProcessStartInfo.

Catégorie

Bibliothèques .NET Core

API affectées
Process.Start
System.Diagnostics.ProcessStartInfo

.NET Core 1.0

UnauthorizedAccessException générée par

FileSystemInfo.Attributes
Dans .NET Core, une exception UnauthorizedAccessException est levée quand l’appelant
tente de définir une valeur d’attribut de fichier sans disposer de l’autorisation d’accès en
écriture.

Description des modifications

Dans .NET Framework, une ArgumentException est levée lorsque l’appelant tente de
définir une valeur d’attribut de fichier dans FileSystemInfo.Attributes mais n’a pas
d’autorisation d’écriture. Dans .NET Core, une exception UnauthorizedAccessException
est levée à la place. (Dans .NET Core, une exception ArgumentException est toujours
levée si l’appelant tente de définir un attribut de fichier non valide.)

Version introduite

1.0
Action recommandée
Modifiez toutes les instructions catch pour intercepter une exception
UnauthorizedAccessException au lieu de, ou en plus de ArgumentException, si
nécessaire.

Catégorie

Bibliothèques .NET Core

API affectées

FileSystemInfo.Attributes

La gestion des exceptions état altéré n’est pas prise en

charge
La gestion des exceptions d’état de processus endommagés dans .NET Core n’est pas
prise en charge.

Description des modifications

Auparavant, les exceptions d’état de processus endommagés pouvaient être

interceptées et gérées par des gestionnaires d’exceptions de code managé, par
exemple, à l’aide d’une instruction try-catch en C#.

À compter de .NET Core 1.0, les exceptions d’état de processus endommagé ne peuvent
pas être gérées par du code managé. Le Common Language Runtime ne fournit pas
d’exceptions d’état de processus endommagés au code managé.

Version introduite

1.0

Action recommandée
Évitez d’avoir à gérer les exceptions d’état de processus altéré en traitant plutôt les
situations qui les entraînent. S’il est absolument nécessaire de gérer les exceptions d’état
de processus endommagés, écrivez le gestionnaire d’exceptions en code C ou C++.
Catégorie
Bibliothèques .NET Core

API affectées

System.Runtime.ExceptionServices.HandleProcessCorruptedStateExceptionsAttribut
e
élément legacyCorruptedStateExceptionsPolicy

Les propriétés UriBuilder ne précèdent plus les caractères

de début
UriBuilder.Fragment ne précède plus un caractère de début # et UriBuilder.Query ne
précède plus un caractère de début ? le cas échéant.

Description des modifications

Dans .NET Framework, les propriétés UriBuilder.Fragment et UriBuilder.Query ajoutent

toujours un caractère # ou ? , respectivement, avant la valeur en cours de stockage. Ce
comportement peut entraîner plusieurs # ou ? caractères dans la valeur stockée si la
chaîne contient déjà l’un de ces caractères de début. Par exemple, la valeur de
UriBuilder.Fragment peut devenir ##main .

À compter de .NET Core 1.0, ces propriétés ne précèdent plus les caractères # ou ? à la
valeur stockée si une valeur est déjà présente au début de la chaîne.

Version introduite
1.0

Action recommandée

Vous n’avez plus besoin de supprimer explicitement l’un de ces caractères de début lors
de la définition des valeurs de propriété. Cela est particulièrement utile lorsque vous
ajoutez des valeurs, car vous n’avez plus besoin de supprimer la # de début ou ?
chaque fois que vous ajoutez.

Par exemple, l’extrait de code suivant montre la différence de comportement entre .NET
Framework et .NET Core.
 C#

var builder = new UriBuilder();

builder.Query = "one=1";
builder.Query += "&two=2";
builder.Query += "&three=3";
builder.Query += "&four=4";

Console.WriteLine(builder.Query);

Dans .NET Framework, la sortie est ????one=1&two=2&three=3&four=4 .

Dans .NET Core, la sortie est ?one=1&two=2&three=3&four=4 .

Catégorie

Bibliothèques .NET Core

API affectées

System.UriBuilder.Fragment
System.UriBuilder.Query

Process.StartInfo lève une exception

InvalidOperationException pour des processus que vous
n’avez pas démarrés
La lecture de la propriété Process.StartInfo pour les processus que votre code n’a pas
démarrés lève une exception InvalidOperationException.

Description des modifications

Dans .NET Framework, l’accès à la propriété Process.StartInfo pour les processus que
votre code n’a pas démarré retourne un objet ProcessStartInfo factice. L’objet factice
contient des valeurs par défaut pour toutes ses propriétés, sauf EnvironmentVariables.

À compter de .NET Core 1.0, si vous lisez la propriété Process.StartInfo d’un processus
que vous n’avez pas démarré (c’est-à-dire en appelant Process.Start), une exception
InvalidOperationException est levée.

Version introduite
1.0

Action recommandée
N’accédez pas à la propriété Process.StartInfo pour les processus que votre code n’a pas
démarrés. Par exemple, ne lisez pas cette propriété pour les processus retournés par
Process.GetProcesses.

Catégorie
Bibliothèques .NET Core

API affectées
System.Diagnostics.Process.StartInfo

Cryptographie
Le paramètre booléen de SignedCms.ComputeSignature est respecté

.NET Core 2.1

Le paramètre booléen de SignedCms.ComputeSignature

est respecté
Dans .NET Core, le paramètre de silent booléen de la méthode
SignedCms.ComputeSignature(CmsSigner, Boolean) est respecté. Une invite de code
confidentiel n’est pas affichée si ce paramètre est défini sur true .

Description des modifications

Dans .NET Framework, le paramètre silent de la méthode
SignedCms.ComputeSignature(CmsSigner, Boolean) est ignoré et une invite de code
confidentiel s’affiche toujours si nécessaire par le fournisseur. Dans .NET Core, le
paramètre silent est respecté et, s’il est défini sur true , une invite de code confidentiel
n’est jamais affichée, même si elle est requise par le fournisseur.
La prise en charge des messages CMS/PKCS #7 a été introduite dans .NET Core dans la
version 2.1.

Version introduite

2.1

Action recommandée

Pour vérifier qu’une invite à entrer un PIN s’affiche si nécessaire, les applications de
bureau doivent appeler SignedCms.ComputeSignature(CmsSigner, Boolean) et définir le
paramètre booléen sur false . Le comportement résultant est le même que sur .NET
Framework, peu importe que le contexte silencieux y soit désactivé ou non.

Catégorie

Cryptographie

API affectées

SignedCms.ComputeSignature(CmsSigner, Boolean)

MSBuild
modification du nom du fichier manifeste de ressource

.NET Core 3.0

Modification du nom du fichier manifeste de ressource

À compter de .NET Core 3.0, dans le cas par défaut, MSBuild génère un autre nom de
fichier manifeste pour les fichiers de ressources.

Version introduite

3.0

Description des modifications

Avant .NET Core 3.0, si aucune LogicalName , ManifestResourceName ou DependentUpon
métadonnées ont été spécifiées pour un élément EmbeddedResource dans le fichier
projet, MSBuild a généré un nom de fichier manifeste dans le modèle <RootNamespace>.
<ResourceFilePathFromProjectRoot>.resources . Si RootNamespace n’est pas défini dans le

fichier projet, il est défini par défaut sur le nom du projet. Par exemple, le nom du
manifeste généré pour un fichier de ressources nommé Form1.resx dans le répertoire du
projet racine était MyProject.Form1.resources.

À compter de .NET Core 3.0, si un fichier de ressources est colocalisé avec un fichier
source du même nom (par exemple, Form1.resx et Form1.cs), MSBuild utilise les
informations de type du fichier source pour générer le nom du fichier manifeste dans le
modèle <Namespace>.<ClassName>.resources . L’espace de noms et le nom de classe sont
extraits du premier type dans le fichier source colocalisé. Par exemple, le nom du
manifeste généré pour un fichier de ressources nommé Form1.resx colocalisé avec un
fichier source nommé Form1.cs est MyNamespace.Form1.resources. La principale chose à
noter est que la première partie du nom de fichier est différente des versions antérieures
de .NET Core (MyNamespace au lieu de MyProject).

７ Notes

Si vous avez LogicalName , ManifestResourceName ou DependentUpon métadonnées

spécifiées sur un élément EmbeddedResource dans le fichier projet, cette
modification n’affecte pas ce fichier de ressources.

Cette modification majeure a été introduite avec l’ajout de la propriété

EmbeddedResourceUseDependentUponConvention aux projets .NET Core. Par défaut, les

fichiers de ressources ne sont pas répertoriés explicitement dans un fichier projet .NET
Core. Ils n’ont donc aucune DependentUpon métadonnées pour spécifier comment
nommer le fichier .resources généré .resources. Lorsque
EmbeddedResourceUseDependentUponConvention est défini sur true , qui est la valeur par

défaut, MSBuild recherche un fichier source colocalisé et extrait un espace de noms et

un nom de classe à partir de ce fichier. Si vous définissez
EmbeddedResourceUseDependentUponConvention sur false , MSBuild génère le nom du

manifeste en fonction du comportement précédent, qui combine RootNamespace et le

chemin du fichier relatif.

Action recommandée

Dans la plupart des cas, aucune action n’est requise de la part du développeur, donc
votre application doit continuer à fonctionner. Toutefois, si cette modification
interrompt votre application, vous pouvez :

Modifiez votre code pour attendre le nouveau nom du manifeste.

Désactivez la nouvelle convention d’affectation de noms en définissant

EmbeddedResourceUseDependentUponConvention sur false dans votre fichier projet.

XML

<PropertyGroup>

<EmbeddedResourceUseDependentUponConvention>false</EmbeddedResourceUseD
ependentUponConvention>
</PropertyGroup>

Catégorie

MSBuild

API affectées

N/A

Réseautage
WebClient.CancelAsync n’annule pas toujours immédiatement

.NET Core 2.0

WebClient.CancelAsync n’annule pas toujours

immédiatement
À compter de .NET Core 2.0, l’appel de WebClient.CancelAsync() n’annule pas
immédiatement la requête si la réponse a commencé à être récupérée.

Description des modifications

Auparavant, l'appel WebClient.CancelAsync() annulait la demande immédiatement. À

compter de .NET Core 2.0, l’appel de WebClient.CancelAsync() annule immédiatement la
requête uniquement si la réponse n’a pas encore commencé à être récupérée. Si la
réponse a commencé à être récupérée, la requête est annulée uniquement après la
lecture complète de la réponse.

Cette modification a été implémentée car l’API WebClient est déconseillée en faveur de
HttpClient.

Version introduite

2.0

Action recommandée

Utilisez la classe System.Net.Http.HttpClient au lieu de System.Net.WebClient, qui est

déconseillée.

Catégorie

Réseautage

API affectées

System.Net.WebClient.CancelAsync()

Windows Forms
La prise en charge de Windows Forms a été ajoutée à .NET Core dans la version 3.0. Si
vous migrez une application Windows Forms de .NET Framework vers .NET Core, les
changements cassants répertoriés ici peuvent affecter votre application.

Contrôles supprimés
Événement CellFormatting non déclenché si l’info-bulle est affichée
Control.DefaultFont a été changé en Segoe UI 9 pt
Modernisation de FolderBrowserDialog
Attribut Serializable supprimé de certains types de Windows Forms
Commutateur de compatibilité AllowUpdateChildControlIndexForTabControls non
pris en charge
Commutateur de compatibilité DomainUpDown.UseLegacyScrolling non pris en
charge
Commutateur de compatibilité DoNotLoadLatestRichEditControl non pris en
charge
 Commutateur de compatibilité DoNotSupportSelectAllShortcutInMultilineTextBox
non pris en charge
Commutateur de compatibilité DontSupportReentrantFilterMessage non pris en
charge
Commutateur de compatibilité EnableVisualStyleValidation non pris en charge
Commutateur de compatibilité UseLegacyContextMenuStripSourceControlValue
non pris en charge
Commutateur de compatibilité UseLegacyImages non pris en charge
À propos et les modèles SplashScreen sont rompus pour Visual Basic
Types dans l’espace de noms Microsoft.VisualBasic.ApplicationServices non
disponibles
Types dans l’espace de noms Microsoft.VisualBasic.Devices non disponibles
Types dans l’espace de noms Microsoft.VisualBasic.MyServices non disponibles

.NET Core 3.1

Contrôles supprimés
À compter de .NET Core 3.1, certains contrôles Windows Forms ne sont plus disponibles.

Description des modifications

À compter de .NET Core 3.1, les différents contrôles Windows Forms ne sont plus
disponibles. Les contrôles de remplacement qui ont une meilleure conception et prise
en charge ont été introduits dans .NET Framework 2.0. Les contrôles déconseillés ont été
précédemment supprimés des boîtes à outils du concepteur, mais ils étaient toujours
disponibles pour être utilisés.

Les types suivants ne sont plus disponibles :

ContextMenu
DataGrid
DataGrid.HitTestType
DataGrid.HitTestInfo
DataGridBoolColumn
DataGridCell
DataGridColumnStyle
DataGridColumnStyle.DataGridColumnHeaderAccessibleObject
DataGridColumnStyle.CompModSwitches
DataGridLineStyle
DataGridParentRowsLabelStyle
 DataGridPreferredColumnWidthTypeConverter
DataGridTableStyle
DataGridTextBox
DataGridTextBoxColumn
GridColumnStylesCollection
GridTablesFactory
GridTableStylesCollection
IDataGridEditingService
IMenuEditorService
MainMenu
Menu
Menu.MenuItemCollection
MenuItem
ToolBar
ToolBarAppearance
ToolBarButton
ToolBar.ToolBarButtonCollection
ToolBarButtonClickEventArgs
ToolBarButtonStyle
ToolBarTextAlign

Version introduite
3.1

Action recommandée
Chaque contrôle supprimé a un contrôle de remplacement recommandé. Reportez-vous
au tableau suivant :

ﾉ Agrandir le tableau

Suppression Remplacement API associées supprimées

du contrôle recommandé
(API)

ContextMenu ContextMenuStrip

DataGrid DataGridView DataGridCell, DataGridRow,

DataGridTableCollection,
DataGridColumnCollection, DataGridTableStyle,
DataGridColumnStyle, DataGridLineStyle,
DataGridParentRowsLabel,
 Suppression Remplacement API associées supprimées
du contrôle recommandé
(API)

DataGridParentRowsLabelStyle,
DataGridBoolColumn, DataGridTextBox,
GridColumnStylesCollection,
GridTableStylesCollection, HitTestType

Menu Principal MenuStrip

Menu ToolStripDropDown, MenuItemCollection

ToolStripDropDownMenu

Élément de ToolStripMenuItem
menu

Barre des ToolStrip Apparence de la barre d'outils

outils

ToolBarButton ToolStripButton ToolBarButtonClickEventArgs,

ToolBarButtonClickEventHandler,
ToolBarButtonStyle, ToolBarTextAlign

Catégorie
Windows Forms

API affectées
System.Windows.Forms.ContextMenu
System.Windows.Forms.GridColumnStylesCollection
System.Windows.Forms.GridTablesFactory
System.Windows.Forms.GridTableStylesCollection
System.Windows.Forms.IDataGridEditingService
System.Windows.Forms.MainMenu
System.Windows.Forms.Menu
System.Windows.Forms.Menu.MenuItemCollection
System.Windows.Forms.MenuItem
System.Windows.Forms.ToolBar
System.Windows.Forms.ToolBar.ToolBarButtonCollection
System.Windows.Forms.ToolBarAppearance
System.Windows.Forms.ToolBarButton
System.Windows.Forms.ToolBarButtonClickEventArgs
System.Windows.Forms.ToolBarButtonStyle
 System.Windows.Forms.ToolBarTextAlign
System.Windows.Forms.DataGrid
System.Windows.Forms.DataGrid.HitTestType
System.Windows.Forms.DataGridBoolColumn
System.Windows.Forms.DataGridCell
System.Windows.Forms.DataGridColumnStyle
System.Windows.Forms.DataGridLineStyle
System.Windows.Forms.DataGridParentRowsLabelStyle
System.Windows.Forms.DataGridPreferredColumnWidthTypeConverter
System.Windows.Forms.DataGridTableStyle
System.Windows.Forms.DataGridTextBox
System.Windows.Forms.DataGridTextBoxColumn
System.Windows.Forms.Design.IMenuEditorService

Événement CellFormatting non déclenché si l’info-bulle

est affichée
Le DataGridView affiche maintenant le texte et les info-bulles d’erreur d’une cellule
lorsqu’elle est pointée par une souris et lorsqu’elle est sélectionnée via le clavier. Si une
info-bulle est affichée, l’événement DataGridView.CellFormatting n’est pas déclenché.

Description des modifications

Avant .NET Core 3.1, une DataGridView dont la propriété ShowCellToolTips était définie
sur true affichait une info-bulle pour le texte et les erreurs d’une cellule lorsque la
cellule était pointée par une souris. Les info-bulles n’étaient pas été affichées lorsqu’une
cellule était été sélectionnée via le clavier (par exemple, à l’aide de la touche Tab, des
touches de raccourci ou de la navigation de direction). Si l’utilisateur a modifié une
cellule, puis, alors que le DataGridView était toujours en mode édition, pointé sur une
cellule qui n’avait pas la propriété ToolTipText définie, un événement de CellFormatting
a été déclenché pour mettre en forme le texte de la cellule à afficher dans la cellule.

Pour répondre aux normes d’accessibilité, à partir de .NET Core 3.1, une DataGridView
dont la propriété ShowCellToolTips était définie sur true affichait les info-bulles pour le
texte et les erreurs d’une cellule non seulement au moment du pointage, mais
également à la sélection via le clavier. En conséquence de cette modification,
l’événement CellFormatting n’est pas déclenché lorsque les cellules dont la propriété
ToolTipText n’est pas définie sont pointées pendant alors que DataGridView est en mode
d’édition. L’événement n’est pas déclenché, car le contenu de la cellule pointée est
affiché sous la forme d’une info-bulle au lieu d’être affiché dans la cellule.

Version introduite

3.1

Action recommandée

Refactorisez tout code qui dépend de l’événement CellFormatting pendant que le

DataGridView est en mode édition.

Catégorie
Windows Forms

API affectées

Aucun

.NET Core 3.0

La police de contrôle par défaut a été modifiée en Segoe

UI 9 pt

Description des modifications

Dans .NET Framework, la propriété Control.DefaultFont a été définie sur Microsoft Sans
Serif 8.25 pt . L’image suivante montre une fenêtre qui utilise la police par défaut.
À compter de .NET Core 3.0, la police par défaut est définie sur Segoe UI 9 pt (la même
police que SystemFonts.MessageBoxFont). En raison de cette modification, les
formulaires et les contrôles ont été agrandis d'environ 27% pour s'adapter à la taille plus
grande de la nouvelle police par défaut. Par exemple:

Cette modification a été apportée pour s’aligner sur les instructions relatives à
l’expérience utilisateur (UX) Windows.

Version introduite
3.0

Action recommandée
En raison de la modification de la taille des formulaires et des contrôles, assurez-vous
que votre application s’affiche correctement.
Pour conserver la police d’origine d’un formulaire unique, définissez sa police par défaut
sur Microsoft Sans Serif 8.25 pt . Par exemple:

C#

public MyForm()
{
InitializeComponent();
Font = new Font(new FontFamily("Microsoft Sans Serif"), 8.25f);
}

Vous pouvez également modifier la police par défaut d’une application entière de l’une
des manières suivantes :

En définissant la propriété MSBuild ApplicationDefaultFont sur « Microsoft Sans

Serif, 8.25pt ». Il s’agit de la technique préférée, car elle permet à Visual Studio
d’utiliser les nouveaux paramètres dans le concepteur.

XML

<PropertyGroup>
<ApplicationDefaultFont>Microsoft Sans Serif,
8.25pt</ApplicationDefaultFont>
</PropertyGroup>

En appelant Application.SetDefaultFont(Font).

C#

class Program
{
[STAThread]
static void Main()
{
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Application.SetHighDpiMode(HighDpiMode.SystemAware);
Application.SetDefaultFont(new Font(new FontFamily("Microsoft
Sans Serif"), 8.25f));
Application.Run(new Form1());
}
}

Catégorie

Windows Forms
API affectées
Aucun.

Modernisation de FolderBrowserDialog
Le contrôle FolderBrowserDialog a changé dans les applications Windows Forms pour
.NET Core.

Description des modifications

Dans le .NET Framework, Windows Forms utilise la boîte de dialogue suivante pour le
contrôle FolderBrowserDialog :

Dans .NET Core 3.0, Windows Forms utilise un contrôle COM plus récent introduit dans
Windows Vista :
Version introduite
3.0

Action recommandée
La boîte de dialogue est automatiquement mise à niveau.

Si vous souhaitez conserver la boîte de dialogue d’origine, définissez la propriété

FolderBrowserDialog.AutoUpgradeEnabled sur false avant d’afficher la boîte de
dialogue, comme illustré par le fragment de code suivant :

C#

var dialog = new FolderBrowserDialog();

dialog.AutoUpgradeEnabled = false;
dialog.ShowDialog();

Catégorie

Windows Forms

API affectées
 FolderBrowserDialog

SerializableAttribute supprimé de certains types Windows

Forms
Le SerializableAttribute a été supprimé de certaines classes Windows Forms qui n’ont
aucun scénario de sérialisation binaire connu.

Description des modifications

Les types suivants sont décorés avec la SerializableAttribute dans .NET Framework, mais
l’attribut a été supprimé dans .NET Core :

System.InvariantComparer

System.ComponentModel.Design.ExceptionCollection
System.ComponentModel.Design.Serialization.CodeDomSerializerException
System.ComponentModel.Design.Serialization.CodeDomComponentSerializationServic
e.CodeDomSerializationStore

System.Drawing.Design.ToolboxItem
System.Resources.ResXNullRef

System.Resources.ResXDataNode

System.Resources.ResXFileRef

System.Windows.Forms.Cursor
System.Windows.Forms.NativeMethods.MSOCRINFOSTRUCT
System.Windows.Forms.NativeMethods.MSG

Historiquement, ce mécanisme de sérialisation a eu de graves problèmes de

maintenance et de sécurité. La maintenance SerializableAttribute sur les types signifie
que ces types doivent être testés pour les modifications de sérialisation de version à
version et potentiellement les modifications de sérialisation de framework à framework.
Cela rend plus difficile l’évolution de ces types et peut être coûteux à maintenir. Ces
types n’ont aucun scénario de sérialisation binaire connu, ce qui réduit l’impact de la
suppression de l’attribut.

Pour plus d'informations, voir Sérialisation binaire.

Version introduite

3.0
Action recommandée
Mettez à jour tout code qui peut dépendre de ces types marqués comme sérialisables.

Catégorie

Windows Forms

API affectées

Aucun

Commutateur de compatibilité
AllowUpdateChildControlIndexForTabControls non pris
en charge
Le commutateur de compatibilité
Switch.System.Windows.Forms.AllowUpdateChildControlIndexForTabControls est pris en

charge dans Windows Forms sur .NET Framework 4.6 et versions ultérieures, mais il n’est
pas pris en charge sur .NET Core ou .NET 5.0 et versions ultérieures.

Description des modifications

Dans .NET Framework 4.6 et versions ultérieures, la sélection d’un onglet réorganise sa
collection de contrôles. Le commutateur de compatibilité
Switch.System.Windows.Forms.AllowUpdateChildControlIndexForTabControls permet à

une application d’ignorer cette réorganisation lorsque ce comportement n’est pas

souhaitable.

Dans .NET Core et .NET 5.0 et versions ultérieures, le commutateur

Switch.System.Windows.Forms.AllowUpdateChildControlIndexForTabControls n’est pas

pris en charge.

Version introduite
3.0

Action recommandée
Supprimez le commutateur. Le commutateur n’est pas pris en charge et aucune autre
fonctionnalité n’est disponible.

Catégorie

Windows Forms

API affectées

Aucun

Commutateur de compatibilité
DomainUpDown.UseLegacyScrolling non pris en charge
Le commutateur de compatibilité
Switch.System.Windows.Forms.DomainUpDown.UseLegacyScrolling , introduit dans .NET

Framework 4.7.1, n’est pas pris en charge dans Windows Forms sur .NET Core ou .NET
5.0 et versions ultérieures.

Description des modifications

À compter de .NET Framework 4.7.1, le commutateur de compatibilité
Switch.System.Windows.Forms.DomainUpDown.UseLegacyScrolling a permis aux

développeurs de refuser les actions indépendantes de DomainUpDown.DownButton() et

de DomainUpDown.UpButton(). Le commutateur a restauré le comportement hérité,
dans lequel le DomainUpDown.UpButton() est ignoré si le texte de contexte est présent,
et le développeur doit utiliser l'action DomainUpDown.DownButton() sur le contrôle
avant d'exécuter l'action DomainUpDown.UpButton(). Pour plus d’informations,
consultez l’élément <AppContextSwitchOverrides>.

Dans .NET Core et .NET 5.0 et versions ultérieures, le commutateur

Switch.System.Windows.Forms.DomainUpDown.UseLegacyScrolling n’est pas pris en charge.

Version introduite
3.0

Action recommandée
Supprimez le commutateur. Le commutateur n’est pas pris en charge et aucune autre
fonctionnalité n’est disponible.

Catégorie

Windows Forms

API affectées

DomainUpDown.DownButton()
DomainUpDown.UpButton()

Commutateur de compatibilité
DoNotLoadLatestRichEditControl non pris en charge
Le commutateur de compatibilité Switch.System.Windows.Forms.UseLegacyImages ,
introduit dans .NET Framework 4.7.1, n’est pas pris en charge dans Windows Forms sur
.NET Core ou .NET 5.0 et versions ultérieures.

Description des modifications

Dans .NET Framework 4.6.2 et les versions précédentes, le contrôle RichTextBox instancie
le contrôle RichEdit Win32 v3.0 et pour les applications qui ciblent .NET Framework
4.7.1, le contrôle RichTextBox instancie RichEdit v4.1 (dans msftedit.dll). Le commutateur
de compatibilité Switch.System.Windows.Forms.DoNotLoadLatestRichEditControl a été
introduit pour permettre aux applications qui ciblent .NET Framework 4.7.1 et versions
ultérieures de refuser le nouveau contrôle RichEdit v4.1 et d’utiliser l’ancien contrôle
RichEdit v3 à la place.

Dans .NET Core et .NET 5.0 et versions ultérieures, le commutateur

Switch.System.Windows.Forms.DoNotLoadLatestRichEditControl n’est pas pris en charge.

Seules les nouvelles versions du contrôle RichTextBox sont prises en charge.

Version introduite
3.0

Action recommandée
Supprimez le commutateur. Le commutateur n’est pas pris en charge et aucune autre
fonctionnalité n’est disponible.

Catégorie

Windows Forms

API affectées

System.Windows.Forms.RichTextBox

Commutateur de compatibilité
DoNotSupportSelectAllShortcutInMultilineTextBox non
pris en charge
Le commutateur de compatibilité
Switch.System.Windows.Forms.DoNotSupportSelectAllShortcutInMultilineTextBox ,

introduit dans .NET Framework 4.6.1, n’est pas pris en charge dans Windows Forms sur
.NET Core et .NET 5.0 et versions ultérieures.

Description des modifications

À partir de .NET Framework 4.6.1, la sélection de la touche de raccourci Ctrl + A dans

un contrôle TextBox permet de sélectionner tout le texte. Dans .NET Framework 4.6 et
les versions précédentes, la sélection de la touche de raccourciCtrl A n’a pas pu
sélectionner tout le texte si les propriétés Textbox.ShortcutsEnabled et ont tous les deux
été définies sur . Le commutateur de compatibilité
Switch.System.Windows.Forms.DoNotSupportSelectAllShortcutInMultilineTextBox a été

introduit dans .NET Framework 4.6.1 pour conserver le comportement d’origine. Pour
plus d’informations, consultez TextBox.ProcessCmdKey.

Dans .NET Core et .NET 5.0 et versions ultérieures, le commutateur

Switch.System.Windows.Forms.DoNotSupportSelectAllShortcutInMultilineTextBox n’est

pas pris en charge.

Version introduite

3.0
Action recommandée
Supprimez le commutateur. Le commutateur n’est pas pris en charge et aucune autre
fonctionnalité n’est disponible.

Catégorie
Windows Forms

API affectées
Aucun

Commutateur de compatibilité
DontSupportReentrantFilterMessage non pris en charge
Le commutateur de compatibilité
Switch.System.Windows.Forms.DontSupportReentrantFilterMessage , introduit dans .NET

Framework 4.6.1, n’est pas pris en charge dans Windows Forms sur .NET Core et .NET 5.0
et versions ultérieures.

Description des modifications

À compter du .NET Framework 4.6.1, le commutateur de compatibilité
Switch.System.Windows.Forms.DontSupportReentrantFilterMessage résout les exceptions

possibles IndexOutOfRangeException lorsque le message Application.FilterMessage est

appelé avec une implémentation de IMessageFilter.PreFilterMessage personnalisée. Pour
plus d’informations, consultez Atténuation : implémentations
IMessageFilter.PreFilterMessage personnalisées.

Dans .NET Core et .NET 5.0 et versions ultérieures, le commutateur

Switch.System.Windows.Forms.DontSupportReentrantFilterMessage n’est pas pris en

charge.

Version introduite
3.0

Action recommandée
Supprimez le commutateur. Le commutateur n’est pas pris en charge et aucune autre
fonctionnalité n’est disponible.

Catégorie

Windows Forms

API affectées

Application.FilterMessage

Commutateur de compatibilité
EnableVisualStyleValidation non pris en charge
Le commutateur de compatibilité
Switch.System.Windows.Forms.EnableVisualStyleValidation n’est pas supporté dans

Windows Forms sous .NET Core ou .NET 5.0 et versions ultérieures.

Description des modifications

Dans .NET Framework, le commutateur de compatibilité
Switch.System.Windows.Forms.EnableVisualStyleValidation a permis à une application

de refuser la validation des styles visuels fournis dans un formulaire numérique.

Dans .NET Core et .NET 5.0 et versions ultérieures, le commutateur

Switch.System.Windows.Forms.EnableVisualStyleValidation n’est pas pris en charge.

Version introduite

3.0

Action recommandée

Supprimez le commutateur. Le commutateur n’est pas pris en charge et aucune autre

fonctionnalité n’est disponible.

Catégorie

Windows Forms
API affectées
Aucun

Commutateur de compatibilité
UseLegacyContextMenuStripSourceControlValue non pris
en charge
Le commutateur de compatibilité
Switch.System.Windows.Forms.UseLegacyContextMenuStripSourceControlValue , qui a été

introduit dans .NET Framework 4.7.2, n’est pas pris en charge dans Windows Forms sur
.NET Core ou .NET 5.0 et versions ultérieures.

Description des modifications

À compter de .NET Framework 4.7.2, le commutateur de compatibilité

Switch.System.Windows.Forms.UseLegacyContextMenuStripSourceControlValue permet au

développeur de refuser le nouveau comportement de la propriété

ContextMenuStrip.SourceControl, qui retourne désormais une référence au contrôle de
code source. Le comportement précédent de la propriété était de retourner null . Pour
plus d’informations, consultez l’élément <AppContextSwitchOverrides>.

Dans .NET Core et .NET 5.0 et versions ultérieures, le commutateur

Switch.System.Windows.Forms.UseLegacyContextMenuStripSourceControlValue n’est pas

pris en charge.

Version introduite
3.0

Action recommandée

Supprimez le commutateur. Le commutateur n’est pas pris en charge et aucune autre

fonctionnalité n’est disponible.

Catégorie
Windows Forms
API affectées
ContextMenuStrip.SourceControl

Commutateur de compatibilité UseLegacyImages non pris

en charge
Le commutateur de compatibilité Switch.System.Windows.Forms.UseLegacyImages , qui a
été introduit dans .NET Framework 4.8, n’est pas pris en charge dans Windows Forms sur
.NET Core ou .NET 5.0 et versions ultérieures.

Description des modifications

À compter de .NET Framework 4.8, le commutateur de compatibilité
Switch.System.Windows.Forms.UseLegacyImages a résolu les problèmes de mise à l’échelle

d’images possibles dans les scénarios ClickOnce dans des environnements DPI élevés.
Lorsqu’il est défini sur true , le commutateur permet à l’utilisateur de restaurer la mise à
l’échelle d’images héritées sur des écrans haute résolution dont la mise à l’échelle est
définie sur plus de 100%. Pour plus d’informations, consultez les notes de publication de
.NET Framework 4.8 sur GitHub .

Dans .NET Core et .NET 5.0 et versions ultérieures, le commutateur

Switch.System.Windows.Forms.UseLegacyImages n’est pas pris en charge.

Version introduite

3.0

Action recommandée
Supprimez le commutateur. Le commutateur n’est pas pris en charge et aucune autre
fonctionnalité n’est disponible.

Catégorie

Windows Forms

API affectées
 Aucun

Les modèles À propos et SplashScreen sont cassés

Les fichiers About.vb et SplashScreen.vb générés par Visual Studio contiennent des
références aux types dans l’espace de noms My qui ne sont pas disponibles .NET Core
3.0 et 3.1.

Version introduite

3.0

Description des modifications

.NET Core 3.0 et 3.1 ne contiennent pas de prise en charge complète de Visual Basic My .
Les modèles de formulaires About et SplashScreen dans les applications Visual Studio
pour Visual Basic Windows Forms font référence aux propriétés du type
My.Application.Info qui ne sont pas disponibles.

Action recommandée

La prise en charge de Visual Basic My a été améliorée dans .NET 5, mettez à niveau votre
projet vers .NET 5 ou version ultérieure.

ou

Corrigez les erreurs du compilateur dans les types About et SplashScreen dans votre
application. Utilisez la classe System.Reflection.Assembly pour obtenir les informations
fournies par le type de My.Application.Info . Un port normal des deux formulaires est
disponible ici.

 Conseil

Il s’agit d’exemples de code et non optimisé. La liste des attributs doit être mise en
cache pour réduire le temps de chargement du formulaire.

À propos de

VB
 Imports System.Reflection

Public NotInheritable Class About

Private Sub about_Load(ByVal sender As System.Object, ByVal e As

System.EventArgs) Handles MyBase.Load
' Set the title of the form.
Dim applicationTitle As String =
Assembly.GetExecutingAssembly().GetCustomAttribute(Of
AssemblyTitleAttribute)()?.Title

If String.IsNullOrEmpty(applicationTitle) Then
applicationTitle =
System.IO.Path.GetFileNameWithoutExtension(Assembly.GetExecutingAssembly().G
etName().Name)
End If

Me.Text = String.Format("About {0}", applicationTitle)

' Initialize all of the text displayed on the About Box.
' TODO: Customize the application's assembly information in the
"Application" pane of the project
' properties dialog (under the "Project" menu).
Me.LabelProductName.Text =
If(Assembly.GetExecutingAssembly().GetCustomAttribute(Of
AssemblyProductAttribute)()?.Product, "")
Me.LabelVersion.Text = String.Format("Version {0}",
Assembly.GetExecutingAssembly().GetName().Version)
Me.LabelCopyright.Text =
If(Assembly.GetExecutingAssembly().GetCustomAttribute(Of
AssemblyCopyrightAttribute)()?.Copyright, "")
Me.LabelCompanyName.Text =
If(Assembly.GetExecutingAssembly().GetCustomAttribute(Of
AssemblyCompanyAttribute)()?.Company, "")
Me.TextBoxDescription.Text =
If(Assembly.GetExecutingAssembly().GetCustomAttribute(Of
AssemblyDescriptionAttribute)()?.Description, "")
End Sub

Private Sub OKButton_Click(ByVal sender As System.Object, ByVal e As

System.EventArgs) Handles OKButton.Click
Me.Close()
End Sub

End Class

SplashScreen

VB

Imports System.Reflection

Public NotInheritable Class SplashScreen

 Private Sub SplashScreen1_Load(ByVal sender As Object, ByVal e As
System.EventArgs) Handles Me.Load
'Set up the dialog text at runtime according to the application's
assembly information.

'TODO: Customize the application's assembly information in the

"Application" pane of the project
' properties dialog (under the "Project" menu).

'Application title
Dim appTitle As String =
Assembly.GetExecutingAssembly().GetCustomAttribute(Of
AssemblyTitleAttribute)()?.Title

If String.IsNullOrEmpty(appTitle) Then
appTitle =
System.IO.Path.GetFileNameWithoutExtension(Assembly.GetExecutingAssembly().G
etName().Name)
End If

ApplicationTitle.Text = appTitle

Dim versionValue = Assembly.GetExecutingAssembly().GetName().Version

'Format the version information using the text set into the Version
control at design time as the
' formatting string. This allows for effective localization if
desired.
' Build and revision information could be included by using the
following code and changing the
' Version control's designtime text to "Version {0}.{1:00}.{2}.{3}"
or something similar. See
' String.Format() in Help for more information.
'
' Version.Text = System.String.Format(Version.Text,
versionValue.Major, versionValue.Minor, versionValue.Build,
versionValue.Revision)

Version.Text = System.String.Format(Version.Text,
versionValue.Major, versionValue.Minor)

'Copyright info
Copyright.Text =
If(Assembly.GetExecutingAssembly().GetCustomAttribute(Of
AssemblyCopyrightAttribute)()?.Copyright, "")
End Sub

End Class

Catégorie
Visual Basic Windows Forms

API affectées
Aucun

Types dans l’espace de noms

Microsoft.VisualBasic.ApplicationServices non disponibles
Les types de l’espace de noms Microsoft.VisualBasic.ApplicationServices ne sont pas
disponibles.

Version introduite
.NET Core 3.0

Description des modifications

Les types de l’espace de noms Microsoft.VisualBasic.ApplicationServices étaient
disponibles dans .NET Framework. Ils ne sont pas disponibles dans .NET Core 3.0 - 3.1.

Les types ont été supprimés pour éviter les dépendances d’assembly inutiles ou les
changements cassants dans les versions suivantes.

Action recommandée
Cet espace de noms a été ajouté dans .NET 5, mettez à niveau votre projet vers .NET 5
ou version ultérieure.

ou

Si votre code dépend de l’utilisation de types Microsoft.VisualBasic.ApplicationServices

et de leurs membres, vous pouvez utiliser un type ou un membre correspondant dans la
bibliothèque de classes .NET. Par exemple, certains membres System.Environment et
System.Security.Principal.WindowsIdentity fournissent des fonctionnalités équivalentes
aux propriétés de la classe Microsoft.VisualBasic.ApplicationServices.User.

Catégorie
Visual Basic
API affectées
Microsoft.VisualBasic.ApplicationServices

Types dans l’espace de noms

Microsoft.VisualBasic.Devices non disponibles
Les types de l’espace de noms Microsoft.VisualBasic.Devices ne sont pas disponibles.

Version introduite

.NET Core 3.0

Description des modifications

Les types de l’espace de noms Microsoft.VisualBasic.Devices étaient disponibles dans
.NET Framework. Ils ne sont pas disponibles dans .NET Core 3.0 - 3.1.

Les types ont été supprimés pour éviter les dépendances d’assembly inutiles ou les
changements cassants dans les versions suivantes.

Action recommandée

Cet espace de noms a été ajouté dans .NET 5, mettez à niveau votre projet vers .NET 5
ou version ultérieure.

ou

Si votre code dépend de l’utilisation de types Microsoft.VisualBasic.Devices et de leurs

membres, vous pouvez utiliser un type ou un membre correspondant dans la
bibliothèque de classes .NET. Par exemple, les fonctionnalités équivalentes à la classe
Microsoft.VisualBasic.Devices.Clock sont fournies par les types System.DateTime et
System.Environment, et les fonctionnalités équivalentes à la classe
Microsoft.VisualBasic.Devices.Ports sont fournies par les types dans l’espace de noms
System.IO.Ports.

Catégorie
Visual Basic
API affectées
Microsoft.VisualBasic.Devices

Types dans l’espace de noms

Microsoft.VisualBasic.MyServices non disponibles
Les types de l’espace de noms Microsoft.VisualBasic.MyServices ne sont pas disponibles.

Version introduite

.NET Core 3.0

Description des modifications

Les types de l’espace de noms Microsoft.VisualBasic.MyServices étaient disponibles dans
.NET Framework. Ils ne sont pas disponibles dans .NET Core 3.0 - 3.1.

Les types ont été supprimés pour éviter les dépendances d’assembly inutiles ou les
changements cassants dans les versions suivantes.

Action recommandée

Cet espace de noms a été ajouté dans .NET 5, mettez à niveau votre projet vers .NET 5
ou version ultérieure.

ou

Si votre code dépend de l’utilisation de Microsoft.VisualBasic.MyServices types et leurs

membres, il existe des types et des membres correspondants dans la bibliothèque de
classes .NET. Voici un mappage des types Microsoft.VisualBasic.MyServices à leurs
types de bibliothèque de classes .NET équivalents :

ﾉ Agrandir le tableau

Type de Type de bibliothèque de classes .NET

Microsoft.VisualBasic.MyServices

ClipboardProxy System.Windows.Clipboard pour les applications WPF,

System.Windows.Forms.Clipboard pour les applications
Windows Forms
 Type de Type de bibliothèque de classes .NET
Microsoft.VisualBasic.MyServices

FileSystemProxy Types dans l'espace de noms System.IO

RegistryProxy Types liés au Registre dans l’espace de noms

Microsoft.Win32

SpecialDirectoriesProxy Environment.GetFolderPath

Catégorie
Visual Basic

API affectées

Microsoft.VisualBasic.MyServices

Voir aussi
API qui lèvent toujours des exceptions sur .NET Core
Technologies .NET Framework non disponibles sur .NET Core
Analyser vos dépendances pour porter
le code de .NET Framework vers .NET
Article • 09/01/2024

Pour identifier les dépendances tierces non prises en charge dans votre projet, vous
devez d’abord comprendre vos dépendances. Les dépendances externes sont les
packages NuGet ou les fichiers .dll que vous référencez dans votre projet, mais que
vous ne générez pas.

Le portage de votre code vers .NET Standard 2.0 ou inférieur garantit qu’il peut être
utilisé avec .NET Framework et .NET. Toutefois, si vous n’avez pas besoin d’utiliser la
bibliothèque avec .NET Framework, envisagez de cibler la dernière version de .NET.

Migrer vos packages NuGet vers

PackageReference
.NET ne peut pas utiliser le fichier packages.config pour les références NuGet. .NET et
.NET Framework peuvent utiliser PackageReference pour spécifier des dépendances de
package. Si vous utilisez packages.config pour spécifier vos packages dans votre projet,
convertissez-le au format PackageReference .

Pour savoir comment migrer, consultez l’article Migrer de packages.config vers

PackageReference.

Mettre à niveau vos packages NuGet

Après avoir migré votre projet au format PackageReference , vérifiez si vos packages sont
compatibles avec .NET.

Tout d’abord, mettez à niveau vos packages vers la dernière version que vous pouvez.
Pour ce faire, utilisez l’interface utilisateur du Gestionnaire de package NuGet dans
Visual Studio. Il est probable que les versions plus récentes de vos dépendances de
package soient déjà compatibles avec .NET Core.

Analyser les dépendances de votre package

Si vous n’avez pas encore vérifié que vos dépendances de package converties et mises à
niveau fonctionnent sur .NET Core, il existe deux façons d’y parvenir :
 Utilisation de nuget.org
Utilisation de l’explorateur de packages NuGet

Utiliser nuget.org
Vous pouvez voir les monikers de framework cible pris en charge par chaque package
sur nuget.org , dans la section Dependencies de la page du package spécifique.

Bien qu’il soit plus facile d’utiliser le site pour vérifier la compatibilité, les informations
de dépendances ne sont pas disponibles sur le site de tous les packages.

Utiliser l’explorateur de packages NuGet

Un package NuGet est lui-même un ensemble de dossiers qui contiennent des
assemblys spécifiques aux plateformes. Vérifiez s’il existe dans le package un dossier qui
contient un assembly compatible.

La méthode la plus facile pour inspecter les dossiers NuGet consiste à utiliser l’outil
NuGet Package Explorer . Après l’avoir installé, effectuez les étapes suivantes pour
afficher les noms de dossiers :

1. Ouvrez NuGet Package Explorer.

2. Cliquez sur Open package from online feed.
3. Recherchez le nom du package.
4. Sélectionnez le nom du package dans les résultats de la recherche et cliquez sur
Open.
5. Développez le dossier lib qui se trouve sur la droite et examinez les noms de
dossiers.

Recherchez un dossier avec des noms à l’aide de l’un des modèles suivants :
netstandardX.Y , netX.Y ou netcoreappX.Y .

Ces valeurs sont les monikers du Framework cible qui correspondent aux versions de
.NET Standard, .NET et .NET Core, qui sont toutes compatibles avec .NET.

） Important

Lorsque vous examinez les monikers de framework cible qu’un package prend en
charge, notez qu’un module moniker de framework cible autre que netstandard*
cible une implémentation spécifique de .NET, telle que .NET 5, .NET Core ou .NET
Framework. À compter de .NET 5, le moniker de framework cible net* (sans
désignation de système d’exploitation) remplace efficacement netstandard*
 comme cible portable. Par exemple, net5.0 cible la surface de l’API .NET 5 et est
conviviale multiplateforme, mais net5.0-windows cible la surface de l’API .NET 5
comme implémentée sur le système d’exploitation Windows.

Mode de compatibilité du .NET Framework

Après avoir analysé les packages NuGet, il est possible que vous constatiez qu’ils ne
ciblent que .NET Framework.

Le mode de compatibilité du .NET Framework a été introduit dans .NET Standard 2.0. Ce
mode de compatibilité permet aux projets .NET Standard et .NET Core de référencer des
bibliothèques .NET Framework. 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.

Lorsque vous référencez des packages NuGet qui ciblent le .NET Framework dans votre
projet, comme Huitian.PowerCollections , vous obtenez un avertissement de package
de secours (NU1701) similaire à l’exemple suivant :

NU1701: Package ‘Huitian.PowerCollections 1.0.0’ was restored using

‘.NETFramework,Version=v4.6.1’ instead of the project target framework

‘.NETStandard,Version=v2.0’. This package may not be fully compatible with your

project.

Cet avertissement s’affiche lorsque vous ajoutez le package et chaque fois que vous
générez une build, pour vous rappeler de tester ce package avec votre projet. Si votre
projet fonctionne comme prévu, vous pouvez supprimer cet avertissement en modifiant
les propriétés du package dans Visual Studio ou en modifiant manuellement le fichier
projet dans votre éditeur de code favori.

Pour supprimer l’avertissement en modifiant le fichier projet, recherchez l’entrée

PackageReference du package pour lequel vous souhaitez supprimer l’avertissement,

puis ajoutez l’attribut NoWarn . L’attribut NoWarn accepte une liste séparée par des
virgules de tous les ID d’avertissement. L’exemple suivant montre comment supprimer
l’avertissement NU1701 pour le package Huitian.PowerCollections en modifiant votre
fichier projet manuellement :

XML

<ItemGroup>
<PackageReference Include="Huitian.PowerCollections" Version="1.0.0"
 NoWarn="NU1701" />
</ItemGroup>

Pour plus d’informations sur la façon de supprimer les avertissements du compilateur

dans Visual Studio, consultez Suppression d’avertissements pour les packages NuGet.

Si les packages NuGet ne s’exécutent pas sur

.NET
Voici quelques actions possibles si un package NuGet dont vous dépendez ne s’exécute
pas sur .NET Core :

Si le projet est open source et hébergé à un endroit comme GitHub, vous pouvez
demander aux développeurs de le modifier.
Vous pouvez contacter l’auteur directement sur nuget.org en recherchant le
package et en cliquant sur Contact Owners sur le côté gauche de la page du
package.
Vous pouvez rechercher un autre package qui s’exécute sur .NET Core et qui réalise
la même tâche que le package que vous utilisez.
Vous pouvez essayer d’écrire vous-même le code qui était exécuté par le package.
Vous pouvez éliminer la dépendance du package en modifiant les fonctionnalités
de votre application, au moins jusqu’à ce qu’une version compatible du package
soit disponible.

N’oubliez pas que les personnes chargées de la maintenance des projets open source et
les éditeurs de packages NuGet sont souvent des bénévoles. Ils offrent leur contribution
car ils s’intéressent à un domaine donné, ils le font gratuitement et ont souvent un autre
travail dans la journée. Pensez-y lorsque vous les contactez pour leur demander de
l’aide sur .NET Core.

Si vous ne parvenez pas à résoudre votre problème avec les options ci-dessus, vous
devrez peut-être porter votre code sur .NET Core à une date ultérieure.

L’équipe .NET aimerait savoir quelles bibliothèques doivent être prioritairement prises
en charge avec .NET Core. Vous pouvez nous envoyer un e-mail à l’adresse
[email protected] afin de nous indiquer les bibliothèques que vous voudriez
utiliser.

Analyser les dépendances non NuGet

Vous avez peut-être une dépendance qui n’est pas un package NuGet, comme une DLL
dans le système de fichiers. Vous pouvez déterminer la portabilité de cette dépendance
en utilisant la fonctionnalité d’analyse binaire de l’Assistant Mise à niveau .NET.

Étapes suivantes
Vue d’ensemble du portage de .NET Framework vers .NET

６ Collaborer avec nous sur Commentaires sur .NET

GitHub .NET est un projet open source.
La source de ce contenu se Sélectionnez un lien pour fournir des
trouve sur GitHub, où vous commentaires :
pouvez également créer et
examiner les problèmes et les  Ouvrir un problème de
demandes de tirage. Pour plus documentation
d’informations, consultez notre
guide du contributeur.  Indiquer des commentaires sur
le produit
Utiliser le pack de compatibilité
Windows pour porter du code vers .NET
Article • 06/06/2023

Certains des problèmes courants que l’on peut rencontrer en portant du code de .NET
Framework vers .NET Core sont des dépendances à des API et à des technologies
propres à .NET Framework. Le pack de compatibilité Windows comporte la plupart de ces
technologies, ce qui facilite la création d’applications .NET et de bibliothèques .NET
Standard.

Le pack de compatibilité est une extension logique de .NET Standard 2.0 qui augmente
considérablement l’ensemble d’API. Le code existant est compilé presque sans
modifications. Pour tenir sa promesse d’ensemble d’API que toutes les implémentations
.NET fournissent, .NET Standard n’inclut pas les technologies qui ne peuvent pas
fonctionner sur toutes les plateformes, telles que le Registre, Windows Management
Instrumentation (WMI) ou les API d’émission de réflexion. Le pack de compatibilité
Windows repose sur .NET Standard et permet d’accéder à ces technologies Windows
uniquement. Il est particulièrement utile pour les clients qui veulent passer à .NET, mais
envisagent de rester sur Windows, au moins pour commencer. Dans ce scénario, vous
pouvez utiliser les technologies Windows uniquement pour supprimer l’obstacle à la
migration.

Contenu d'un package

Le pack de compatibilité Windows est fourni via le package NuGet
Microsoft.Windows.Compatibility et peut être référencé à partir de projets ciblant
.NET ou .NET Standard.

Il fournit environ 20 000 API, dont des API Windows uniquement ainsi des API
multiplateformes des domaines technologiques suivants :

Pages de codes
CodeDom
Configuration
Services d'annuaire
Dessin
ODBC
Autorisations
Ports
Listes de contrôle d’accès Windows
 Windows Communication Foundation (WCF)
Chiffrement Windows
Journal des événements Windows
Windows Management Instrumentation (WMI)
Compteurs de performances Windows
Registre Windows
Mise en cache Windows Runtime
services Windows

Pour plus d’informations, consultez la spécification du pack de compatibilité .

Bien démarrer
1. Avant le portage, veillez à examiner le processus de portage.

2. Lors du portage du code existant vers .NET ou .NET Standard, installez le package
NuGet Microsoft.Windows.Compatibility .

Si vous souhaitez rester sur Windows, vous êtes prêt.

3. Si vous souhaitez exécuter l’application .NET ou la bibliothèque .NET Standard sur

Linux ou macOS, utilisez l’analyseur de compatibilité de la plateforme pour trouver
l’usage des API qui ne fonctionnent pas sur toutes les plateformes.

4. Supprimez les usages de ces API, remplacez-les par des alternatives

multiplateformes ou protégez-les à l’aide d’une vérification de la plateforme, par
exemple :

C#

private static string GetLoggingPath()

{
// Verify the code is running on Windows.
if (RuntimeInformation.IsOSPlatform(OSPlatform.Windows))
{
using (var key =
Registry.CurrentUser.OpenSubKey(@"Software\Fabrikam\AssetManagement"))
{
if (key?.GetValue("LoggingDirectoryPath") is string
configuredPath)
return configuredPath;
}
}

// This is either not running on Windows or no logging path was

configured,
// so just use the path for non-roaming user-specific data files.
 var appDataPath =
Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationDat
a);
return Path.Combine(appDataPath, "Fabrikam", "AssetManagement",
"Logging");
}

Pour obtenir une démonstration, regardez la vidéo de Channel 9 sur le pack de

compatibilité Windows.
Technologies .NET Framework
indisponibles sur .NET
Article • 31/01/2025

Plusieurs technologies disponibles pour les bibliothèques .NET Framework ne sont pas
disponibles pour une utilisation avec .NET 6+, telles que les domaines d’application, la
communication à distance et la sécurité d’accès au code (CAS). Si vos bibliothèques
s’appuient sur une ou plusieurs des technologies répertoriées sur cette page, tenez
compte des autres approches mentionnées.

Pour plus d’informations sur la compatibilité des API, consultez Changements cassants
dans .NET.

Domaines d’application
Les domaines d’application (AppDomains) isolent les applications les unes des autres.
Les domaines d’application nécessitent la prise en charge du runtime et sont coûteux en
ressources. La création de domaines d’application supplémentaires n’est pas prise en
charge et il n’existe aucun plan pour ajouter cette fonctionnalité à l’avenir. Pour
l’isolation du code, utilisez des processus ou des conteneurs distincts comme
alternative. Pour charger dynamiquement des assemblys, utilisez la classe
AssemblyLoadContext.

Pour faciliter la migration du code à partir de .NET Framework, .NET 6+ expose une
partie de la surface d’API AppDomain. Certaines des API fonctionnent normalement (par
exemple, AppDomain.UnhandledException), certains membres ne font rien (par
exemple, SetCachePath), et certains d’entre eux lèvent PlatformNotSupportedException
(par exemple, CreateDomain). Vérifiez les types que vous utilisez par rapport à la source
de référence System.AppDomain dans le référentiel GitHub dotnet/runtime . Veillez
à sélectionner la branche qui correspond à votre version implémentée.

Communication à distance
La communication à distance .NET n’est pas prise en charge sur .NET 6+. Le remoting
.NET a été identifié comme architecture problématique. Il est utilisé pour communiquer
entre les domaines d’application, qui ne sont plus pris en charge. Par ailleurs, le
remoting requiert la prise en charge du runtime, dont la maintenance est coûteuse.
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 les scénarios plus
complexes, le projet open source StreamJsonRpc fournit un framework de remoting
standard .NET multiplateforme qui fonctionne sur des connexions de flux ou de canal
existantes.

Sur plusieurs ordinateurs, utilisez une solution basée sur le réseau comme alternative.
De préférence, utilisez un protocole de texte brut à faible charge, tel que HTTP. Le
serveur web Kestrel, qui est le serveur web utilisé par ASP.NET Core, est une option ici.
Envisagez également d’utiliser System.Net.Sockets pour les scénarios inter-ordinateurs
basés sur le réseau. StreamJsonRpc, mentionné précédemment, peut être utilisé pour la
communication JSON ou binaire (via MessagePack) sur des sockets web.

Pour plus d'options de messagerie, consultez les projets de développement .NET open
source : Messagerie .

Étant donné que la liaison à distance n'est pas prise en charge, les appels à
BeginInvoke() et EndInvoke() sur les objets délégués généreront une
PlatformNotSupportedException . Pour plus d’informations, consultez Migration des

appels BeginInvoke délégués pour .NET Core .

Sécurité de l’accès au code (CAS)

Sandboxing, qui s’appuie sur le runtime ou l’infrastructure pour limiter les ressources
qu’une application managée ou une bibliothèque utilise ou exécute, n’est pas prise en
charge sur .NET Framework et n’est donc pas prise en charge sur .NET 6+. Le cas n’est
plus traité comme une limite de sécurité, car il existe trop de cas dans .NET Framework
et dans le runtime où une élévation de privilèges se produit. En outre, le CAS rend
l'implémentation plus complexe et a souvent des conséquences en termes de
correctitude et de performance pour les applications qui ne prévoient pas de l'utiliser.

Utilisez les limites de sécurité fournies par le système d’exploitation, telles que la
virtualisation, les conteneurs ou les comptes d’utilisateur, pour exécuter des processus
avec l’ensemble minimal de privilèges.

Transparence de la sécurité
Tout comme la sécurité d’accès du code, la transparence de la sécurité sépare le code
sandbox du code critique de sécurité d’une manière déclarative, mais n’est plus prise en
charge en tant que limite de sécurité. Cette fonctionnalité est fortement utilisée par
Silverlight.

Pour exécuter des processus avec le moins de privilèges, utilisez 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 par .NET 6+.

Workflow Foundation
Windows Workflow Foundation (WF) n’est pas pris en charge dans .NET 6+. Pour obtenir
une alternative, consultez CoreWF .

 Conseil

Le serveur Windows Communication Foundation (WCF) peut être utilisé dans .NET
6+ à l’aide des packages NuGet CoreWCF . Pour plus d’informations, consultez
CoreWCF 1.0 a été publié .

Certaines API d’émission de réflexion ne sont

pas prises en charge
.NET 8 et versions antérieures de .NET (Core) ne prennent pas en charge
l’enregistrement d’assemblys générés par les API System.Reflection.Emit, et la méthode
AssemblyBuilder.Save n’est pas disponible. En outre, les champs suivants de
l’énumération AssemblyBuilderAccess ne sont pas disponibles :

ReflectionOnly
RunAndSave
Save

Dans .NET 9, une PersistedAssemblyBuilder a été implémentée et la méthode

AssemblyBuilder.Save a été rajoutée à la bibliothèque d’émission de réflexion. Pour en
savoir plus sur l’utilisation de cette API, consultez classe
System.Reflection.Emit.PersistedAssemblyBuilder.
Pour plus d’informations sur les différentes implémentations AssemblyBuilder dans .NET,
consultez classe System.Reflection.Emit.AssemblyBuilder.

Chargement d’assemblys multimodules

Les assemblys qui se composent de plusieurs modules ( OutputType=Module dans
MSBuild) ne sont pas pris en charge dans .NET 6+.

En guise d’alternative, envisagez de fusionner les modules individuels dans un seul

fichier d’assembly.

Blocs de script XSLT

Les blocs de script XSLT sont pris en charge uniquement dans .NET Framework. Ils ne
sont pas pris en charge sur .NET 6 ou version ultérieure.

Voir aussi
Vue d’ensemble du portage de .NET Framework vers .NET
Rechercher les API non prises en charge
dans votre code
Article • 10/05/2023

Les API de votre code .NET Framework peuvent ne pas être prises en charge dans .NET
pour de nombreuses raisons. Ces raisons vont de la simple à la correction, telle qu’une
modification d’espace de noms, à la résolution plus difficile, par exemple quand
l’intégralité d’une technologie n’est pas prise en charge. La première étape consiste à
déterminer les API qui ne sont plus prises en charge, puis à identifier le correctif
approprié.

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 .NET Portability Analyzer.

Assistant Mise à niveau

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 l’analyseur de portabilité .NET entre autres outils et guide le processus
de migration. Pour plus d’informations sur l’outil, consultez Vue d’ensemble de
l’Assistant Mise à niveau .NET.
API qui lèvent toujours des exceptions
sur .NET Core et .NET 5+
Article • 22/08/2023

Les API suivantes lèveront toujours une exception sur .NET (Core) sur l’ensemble ou un
sous-ensemble des plateformes. Dans la plupart des cas, l’exception levée est
PlatformNotSupportedException.

Cet article organise les API affectées par espace de noms.

７ Notes

Cet article n’est pas définitif. Il ne s’agit pas d’une liste complète des API qui
lèvent des exceptions sur .NET 5+.
Cet article n’inclut pas les implémentations d’interface explicites pour la
sérialisation binaire qui lèvent sur .NET 5+. Pour plus d’informations, consultez
Sérialisation binaire dans .NET Core.

Système
Membre Plateformes qui lèvent une
exception

AppDomain.CreateDomain Tous

AppDomain.ExecuteAssembly(String, String[], Byte[], Tous

AssemblyHashAlgorithm)

AppDomain.Unload(AppDomain) Tous

Console.CapsLock Linux et macOS

Console.NumberLock Linux et macOS

Delegate.GetObjectData(SerializationInfo, StreamingContext) Tous

Exception.SerializeObjectState Tous

MarshalByRefObject.GetLifetimeService() Tous

MarshalByRefObject.InitializeLifetimeService() Tous
Membre Plateformes qui lèvent une
exception

OperatingSystem.GetObjectData(SerializationInfo, Tous
StreamingContext)

Type.ReflectionOnlyGetType(String, Boolean, Boolean) Tous

System.CodeDom.Compiler
Membre Plateformes qui lèvent une exception

CodeDomProvider.CompileAssemblyFromDom Tous

CodeDomProvider.CompileAssemblyFromFile Tous

CodeDomProvider.CompileAssemblyFromSource Tous

System.Collections.Specialized
Membre Plateformes qui lèvent
une exception

NameObjectCollectionBase(SerializationInfo, StreamingContext) Tous

NameObjectCollectionBase.GetObjectData(SerializationInfo, Tous
StreamingContext)

NameObjectCollectionBase.OnDeserialization(Object) Tous

System.Configuration
Membre Plateformes qui lèvent
une exception

System.Configuration.RsaProtectedConfigurationProvider (tous les Tous

membres)

System.Console
Membre Plateformes qui lèvent une exception

Console.Beep() Linux et macOS

Membre Plateformes qui lèvent une exception

Console.BufferHeight (ensemble uniquement) Linux et macOS

Console.BufferWidth (ensemble uniquement) Linux et macOS

Console.CursorSize (ensemble uniquement) Linux et macOS

Console.CursorVisible (get uniquement) Linux et macOS

Console.MoveBufferArea Linux et macOS

Console.SetWindowPosition Linux et macOS

Console.SetWindowSize Linux et macOS

Console.Title (get uniquement) Linux et macOS

Console.WindowHeight (ensemble uniquement) Linux et macOS

Console.WindowLeft (ensemble uniquement) Linux et macOS

Console.WindowTop (ensemble uniquement) Linux et macOS

Console.WindowWidth (ensemble uniquement) Linux et macOS

System.Data.Common
Membre Plateformes qui lèvent une
exception

DbDataReader.GetSchemaTable (lève Tous

NotSupportedException)

System.Diagnostics.Process
Membre Plateformes qui lèvent une
exception

Process.MaxWorkingSet (ensemble uniquement) Linux

Process.MinWorkingSet (ensemble uniquement) Linux

Process.ProcessorAffinity macOS

Process.MainWindowHandle Linux et macOS

Process.Start(String, String, String, SecureString, String) Linux et macOS

Membre Plateformes qui lèvent une
exception

Process.Start(String, String, SecureString, String) Linux et macOS

ProcessStartInfo.UserName Linux et macOS

ProcessStartInfo.PasswordInClearText Linux et macOS

ProcessStartInfo.Domain Linux et macOS

ProcessStartInfo.LoadUserProfile Linux et macOS

ProcessThread.BasePriority (ensemble uniquement) Linux et macOS

ProcessThread.BasePriority (get uniquement) macOS

ProcessThread.ProcessorAffinity (ensemble Linux et macOS

uniquement)

System.IO
Membre Plateformes qui lèvent une
exception

FileSystemInfo(SerializationInfo, StreamingContext) Tous

FileSystemInfo.GetObjectData(SerializationInfo, Tous
StreamingContext)

System.IO.Pipes
Membre Plateformes qui lèvent une exception

NamedPipeClientStream.NumberOfServerInstances Linux et macOS

NamedPipeServerStream.GetImpersonationUserName() Linux et macOS

PipeStream.InBufferSize Linux et macOS

PipeStream.OutBufferSize Linux et macOS

PipeStream.ReadMode (ensemble uniquement) Linux et macOS

PipeStream.WaitForPipeDrain() Linux et macOS

System.Media
Membre Plateformes qui lèvent une exception

SoundPlayer(SerializationInfo, StreamingContext) Tous

System.Net
Membre Plateformes qui lèvent une
exception

AuthenticationManager.Authenticate(String, WebRequest, Tous

ICredentials)

AuthenticationManager.PreAuthenticate(WebRequest, Tous
ICredentials)

FileWebRequest(SerializationInfo, StreamingContext) Tous

FileWebRequest.GetObjectData(SerializationInfo, Tous
StreamingContext)

FileWebResponse(SerializationInfo, StreamingContext) Tous

FileWebResponse.GetObjectData(SerializationInfo, Tous
StreamingContext)

HttpWebRequest(SerializationInfo, StreamingContext) Tous

HttpWebRequest.GetObjectData(SerializationInfo, Tous
StreamingContext)

HttpWebResponse(SerializationInfo, StreamingContext) Tous

HttpWebResponse.GetObjectData(SerializationInfo, Tous
StreamingContext)

WebProxy(SerializationInfo, StreamingContext) Tous

WebProxy.GetDefaultProxy() Tous

WebProxy.GetObjectData Tous

WebRequest(SerializationInfo, StreamingContext) Tous

WebRequest.GetObjectData(SerializationInfo, StreamingContext) Tous

WebResponse(SerializationInfo, StreamingContext) Tous

Membre Plateformes qui lèvent une
exception

WebResponse.GetObjectData(SerializationInfo, Tous
StreamingContext)

System.Net.NetworkInformation
Membre Plateformes qui lèvent une exception

Ping.Send Windows (UWP)

System.Net.Sockets
Membre Plateformes qui lèvent une exception

Socket(SocketInformation) Tous

Socket.DuplicateAndClose(Int32) Tous

System.Net.WebSockets
Membre Plateformes qui lèvent une exception

WebSocket.RegisterPrefixes() Tous

System.Reflection
Membre Plateformes qui lèvent une
exception

Assembly.CodeBase Tous

Assembly.EscapedCodeBase Tous

Assembly.ReflectionOnlyLoad Tous

Assembly.ReflectionOnlyLoadFrom(String) Tous

AssemblyName.GetObjectData(SerializationInfo, Tous
StreamingContext)

AssemblyName.KeyPair Tous
Membre Plateformes qui lèvent une
exception

AssemblyName.OnDeserialization(Object) Tous

StrongNameKeyPair Tous

StrongNameKeyPair.PublicKey Tous

System.Runtime.CompilerServices
Membre Plateformes qui lèvent une exception

DebugInfoGenerator.CreatePdbGenerator() Tous

System.Runtime.InteropServices
Membre Plateformes qui lèvent une
exception

IDispatchImplAttribute Tous

Marshal.GetIDispatchForObject(Object) Tous

RuntimeEnvironment.SystemConfigurationFile Tous

RuntimeEnvironment.GetRuntimeInterfaceAsIntPtr(Guid, Tous
Guid)

RuntimeEnvironment.GetRuntimeInterfaceAsObject(Guid, Tous
Guid)

WindowsRuntimeMarshal.StringToHString(String) Linux et macOS

WindowsRuntimeMarshal.PtrToStringHString(IntPtr) Linux et macOS

WindowsRuntimeMarshal.FreeHString(IntPtr) Linux et macOS

System.Runtime.Serialization
 Membre Plateformes
qui lèvent
une
exception

System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Serialize(Stream, Tous
Object)*

BinaryFormatter.Deserialize(Stream)* Tous

XsdDataContractExporter.Schemas Toutes

* .NET 8 et versions ultérieures uniquement pour tous les types de projets, à l’exception
de Windows Forms et WPF.

System.Security
Membre Plateformes qui lèvent une
exception

CodeAccessPermission.Deny() Tous

CodeAccessPermission.PermitOnly() Tous

PermissionSet.ConvertPermissionSet(String, Byte[], String) Tous

PermissionSet.Deny() Tous

PermissionSet.PermitOnly() Tous

SecurityContext.Capture() Tous

SecurityContext.CreateCopy() Tous

SecurityContext.Dispose() Tous

SecurityContext.IsFlowSuppressed() Tous

SecurityContext.IsWindowsIdentityFlowSuppressed() Tous

SecurityContext.RestoreFlow() Tous

SecurityContext.Run(SecurityContext, ContextCallback, Tous

Object)

SecurityContext.SuppressFlow() Tous

SecurityContext.SuppressFlowWindowsIdentity() Tous
System.Security.Claims
Membre Plateformes qui lèvent une
exception

ClaimsPrincipal(SerializationInfo, StreamingContext) Tous

ClaimsPrincipal.GetObjectData(SerializationInfo, Tous
StreamingContext)

ClaimsIdentity(SerializationInfo) Tous

ClaimsIdentity(SerializationInfo, StreamingContext) Tous

ClaimsIdentity.GetObjectData(SerializationInfo, Tous
StreamingContext)

System.Security.Cryptography
Membre Plateformes qui
lèvent une
exception

AsymmetricAlgorithm.Create(String) Tous

System.Security.Cryptography.CngAlgorithm Linux et macOS

System.Security.Cryptography.CngAlgorithmGroup Linux et macOS

System.Security.Cryptography.CngKey Linux et macOS

System.Security.Cryptography.CngKeyBlobFormat Linux et macOS

System.Security.Cryptography.CngKeyCreationParameters Linux et macOS

System.Security.Cryptography.CngProvider Linux et macOS

System.Security.Cryptography.CngUIPolicy Linux et macOS

CryptoConfig.EncodeOID(String) Tous

CspKeyContainerInfo Linux et macOS

CspKeyContainerInfo.Accessible Linux et macOS

CspKeyContainerInfo.Exportable Linux et macOS

CspKeyContainerInfo.HardwareDevice Linux et macOS

CspKeyContainerInfo.KeyContainerName Linux et macOS

Membre Plateformes qui
lèvent une
exception

CspKeyContainerInfo.KeyNumber Linux et macOS

CspKeyContainerInfo.MachineKeyStore Linux et macOS

CspKeyContainerInfo.Protected Linux et macOS

CspKeyContainerInfo.ProviderName Linux et macOS

CspKeyContainerInfo.ProviderType Linux et macOS

CspKeyContainerInfo.RandomlyGenerated Linux et macOS

CspKeyContainerInfo.Removable Linux et macOS

CspKeyContainerInfo.UniqueKeyContainerName Linux et macOS

ECDiffieHellmanCng.FromXmlString(String, ECKeyXmlFormat) Tous

ECDiffieHellmanCng.ToXmlString(ECKeyXmlFormat) Tous

ECDiffieHellmanCngPublicKey.FromXmlString(String) Tous

ECDiffieHellmanCngPublicKey.ToXmlString() Tous

ECDiffieHellmanPublicKey.ToByteArray() Linux et macOS

ECDiffieHellmanPublicKey.ToXmlString() Tous

ECDsaCng.FromXmlString(String, ECKeyXmlFormat) Tous

ECDsaCng.ToXmlString(ECKeyXmlFormat) Tous

HashAlgorithm.Create() Tous

HMAC.Create() Tous

HMAC.Create(String) Tous

HMAC.HashCore Tous

HMAC.HashFinal Tous

HMAC.Initialize Tous

KeyedHashAlgorithm.Create() Tous

KeyedHashAlgorithm.Create(String) Tous

ProtectedData.Protect Linux et macOS

Membre Plateformes qui
lèvent une
exception

ProtectedData.Unprotect Linux et macOS

System.Security.Cryptography.RSACryptoServiceProvider.DecryptValue(Byte[]) Tous

System.Security.Cryptography.RSACryptoServiceProvider.EncryptValue(Byte[]) Tous

System.Security.Cryptography.RSA.DecryptValue(Byte[]) Tous

System.Security.Cryptography.RSA.EncryptValue(Byte[]) Tous

RSA.FromXmlString Tous

RSA.ToXmlString Tous

SymmetricAlgorithm.Create() Tous

SymmetricAlgorithm.Create(String) Tous

System.Security.Cryptography.Pkcs
Membre Plateformes qui lèvent une exception

CmsSigner(CspParameters) Tous

SignerInfo.ComputeCounterSignature() Tous

System.Security.Cryptography.X509Certificates
Membre Plateformes qui lèvent une exception

X509Certificate(SerializationInfo, StreamingContext) Tous

X509Certificate.Import Tous

X509Certificate2(SerializationInfo, StreamingContext) Tous

X509Certificate2.PrivateKey (ensemble uniquement) Tous

System.Security.Authentication.ExtendedProtection
Membre Plateformes qui lèvent une
exception

ExtendedProtectionPolicy(SerializationInfo, Tous
StreamingContext)

System.Security.Policy
Membre Plateformes qui lèvent une
exception

Hash.GetObjectData(SerializationInfo, Tous
StreamingContext)

System.ServiceProcess.ServiceController
Membre Plateformes qui lèvent une exception

TimeoutException(SerializationInfo, StreamingContext) Tous

System.Text.RegularExpressions
Membre Plateformes qui lèvent une exception

Regex.CompileToAssembly Tous

System.Threading
Membre Plateformes qui lèvent une
exception

CompressedStack.GetObjectData(SerializationInfo, Tous
StreamingContext)

ExecutionContext.GetObjectData(SerializationInfo, Tous
StreamingContext)

Thread.Abort Tous

Thread.ResetAbort() Tous

Thread.Resume() Tous
Membre Plateformes qui lèvent une
exception

Thread.Suspend() Tous

System.Xml
Membre Plateformes qui
lèvent une
exception

XmlDictionaryReader.CreateMtomReader(Byte[], Int32, Int32, Encoding[], Tous

String, XmlDictionaryReaderQuotas, Int32, OnXmlDictionaryReaderClose)

XmlDictionaryReader.CreateMtomReader(Stream, Encoding[], String, Tous

XmlDictionaryReaderQuotas, Int32, OnXmlDictionaryReaderClose)

XmlDictionaryWriter.CreateMtomWriter(Stream, Encoding, Int32, String, Tous

String, String, Boolean, Boolean)

Voir aussi
Changements cassants pour la migration de .NET Framework vers .NET Core
Sérialisation binaire dans .NET Core
Analyseur de portabilité .NET
Conditions préalables au portage du
code
Article • 10/05/2023

Apportez les modifications nécessaires pour générer et exécuter une application .NET
avant de commencer le travail de portage de votre code. Ces modifications peuvent être
effectuées tout en créant et exécutant une application .NET Framework.

Mettre à niveau vers les outils requis

Effectuez une mise à niveau vers une version de MSBuild/Visual Studio qui prend en
charge la version de .NET que vous ciblez. Pour plus d’informations, consultez la relation
de contrôle de version entre .NET, MSBuild et Visual Studio.

Mettre à jour la version cible de .NET

Framework
Nous vous recommandons de cibler votre application .NET Framework vers la version
4.7.2 ou ultérieure. Cela permet de garantir la disponibilité des dernières API de
remplacement pour les cas où .NET Standard ne prend pas en charge les API existantes.

Pour chacun de vos projets que vous voulez porter, procédez comme suit dans Visual
Studio :

1. Cliquez avec le bouton droit sur le projet et sélectionnez Propriétés.

2. Dans la liste déroulante Version cible de .NET Framework, sélectionnez .NET
Framework 4.7.2.
3. Recompilez le projet.

Vos projets ciblent maintenant .NET Framework 4.7.2. Utilisez cette version de .NET
Framework comme base pour le portage du code.

Passer au format PackageReference

Convertissez toutes les références au format PackageReference.

Convertir au format de projet de style SDK

Convertissez vos projets au format de style SDK.

Mettre à jour les dépendances

Mettre à jour les dépendances vers leur dernière version disponible et vers la version
.NET Standard si possible.

Étapes suivantes
Créer un plan de portage
Créer un plan de portage
Article • 21/03/2023

Nous recommandons d’utiliser l’Assistant Mise à niveau de .NET de Visual Studio pour
mettre à jour le code .NET Framework vers les dernières versions de .NET. Pour plus
d’informations, consultez le blog Mise à niveau de vos projets .NET avec Visual Studio .

７ Notes

Nous sommes en train de déprécier le port d’API en faveur de l’intégration de

l’analyse binaire directement dans l’Assistant Mise à niveau .NET . Dans les
prochains mois, nous allons arrêter le service back-end du port d’API, ce qui
nécessitera l’utilisation de l’outil hors connexion. Pour plus d’informations,
consultez GitHub : dépôt Port d’API .NET .*

Avant de passer directement au code, prenez le temps d’effectuer les étapes de pré-
migration recommandées. Cet article vous donne un aperçu des types de problèmes
potentiels et vous aide à opter pour l’approche la plus logique.

Porter votre code

Veillez à suivre les conditions préalables au portage du code avant de continuer. Soyez
prêt à choisir la meilleure approche pour vous et à commencer le portage du code.

Se concentrer principalement sur le compilateur

Cette approche fonctionne bien pour les projets de faible envergure ou les projets qui
utilisent un nombre restreint d’API .NET Framework. Elle est simple :

1. Si vous le souhaitez, exécutez ApiPort sur votre projet. Si vous exécutez ApiPort,
prenez connaissance du rapport sur les problèmes que vous devrez résoudre.
2. Copiez tout votre code dans un nouveau projet .NET.
3. Pendant que vous vous référez au rapport de portabilité (s’il a été généré), résolvez
les erreurs du compilateur jusqu’à ce que le projet se compile intégralement.

Bien qu’elle ne soit pas structurée, cette approche axée sur le code résout souvent
rapidement les problèmes. Un projet contenant uniquement des modèles de données
pourrait constituer un candidat idéal à cette approche.
Rester sur .NET Framework jusqu’à la résolution des
problèmes de portabilité
Cette approche est peut-être la meilleure si vous préférez avoir du code compilable
pendant tout le processus. L’approche est la suivante :

1. Exécutez ApiPort sur un projet.

2. Résolvez les problèmes en utilisant différentes API portables.
3. Notez toutes les zones où vous n’avez pas la possibilité d’utiliser une solution de
rechange directe.
4. Répétez les étapes précédentes pour tous les projets à porter jusqu’à ce que vous
ayez la certitude que tous sont prêts à être copiés dans un nouveau projet .NET.
5. Copiez le code dans un nouveau projet .NET.
6. Résolvez tous les problèmes pour lesquels vous avez noté qu’il n’existe pas de
solution de rechange directe.

Cette approche prudente est plus structurée que celle qui consiste à résoudre
simplement les erreurs de compilation, mais elle reste relativement centrée sur le code
et présente l’avantage de toujours conserver du code compilable. Les moyens de
résoudre les problèmes qui n’ont pas pu être traités en utilisant simplement une autre
API peuvent varier considérablement. Il peut être nécessaire de développer un plan plus
complet pour certains projets, ce qui est couvert par l’approche suivante.

Développer un plan d’attaque complet

Cette approche est peut-être la meilleure pour les projets complexes et de grande
envergure, dans lesquels il peut être nécessaire de restructurer le code ou de réécrire
complètement certains passages pour prendre en charge .NET. L’approche est la
suivante :

1. Exécutez ApiPort sur un projet.

2. Déterminez les endroits où chaque type non portable est utilisé et l’impact sur la
portabilité globale.

Déterminez la nature de ces types. Sont-ils peu nombreux mais fréquemment

utilisés ? Sont-ils nombreux mais rarement utilisés ? Leur utilisation est-elle
concentrée ou est-elle répartie à travers tout le code ?
Est-il facile d’isoler le code non portable, afin de le traiter plus facilement ?
Faut-il refactoriser le code ?
Pour les types qui ne sont pas portables, y a-t-il des API alternatives qui
accomplissent la même tâche ? Par exemple, si vous utilisez la classe
 WebClient, utilisez la classe HttpClient à la place.
Existe-t-il d’autres API portables permettant d’accomplir une tâche, même s’il
ne s’agit pas d’un remplacement immédiat ? Par exemple, si vous utilisez
XmlSchema pour analyser le code XML, mais que vous n’avez pas besoin de
la détection de schéma XML, vous pouvez utiliser les API System.Xml.Linq et
implémenter l’analyse par vous-même au lieu de dépendre d’une API.

3. Si vous avez des assemblys difficiles à porter, est-il intéressant de les laisser sur le
.NET Framework pour l’instant ? Voici quelques possibilités d’opérations à prendre
en considération :

Certaines des fonctionnalités de votre bibliothèque pourraient ne pas être

compatibles avec .NET, car elles dépendent trop des fonctionnalités propres à
.NET Framework ou à Windows. Cela vaut-il la peine de laisser cette
fonctionnalité de côté pour le moment et de publier une version .NET
temporaire de votre bibliothèque avec moins de fonctionnalités jusqu’à ce
que des ressources soient disponibles pour porter ces fonctionnalités ?
Une refactorisation serait-elle utile ?

4. Est-il raisonnable d’écrire votre propre implémentation d’une API .NET Framework
non disponible ?

Vous pouvez envisager de copier, de modifier et d’utiliser du code provenant de la

source de référence de .NET Framework . Le code source de référence est sous
licence du MIT , ce qui vous laisse la liberté d’utiliser la source comme base pour
votre propre code. Veillez simplement à mentionner correctement ce qui est
propriété de Microsoft dans votre code.

5. Répétez ce processus si nécessaire pour les différents projets.

La phase d’analyse peut prendre un certain temps, selon la taille de votre code base.
Passer du temps sur cette phase pour déterminer précisément l’étendue des
modifications nécessaires et pour développer un plan fait en général gagner du temps
finalement, en particulier en cas de codebase complexe.

Votre plan peut impliquer des modifications importantes de votre codebase tout en
continuant à cibler .NET Framework 4.7.2. Cela en fait une version plus structurée de
l’approche précédente. La mise en œuvre du plan dépend du code base.

Approche mixte
Il est probable que vous allez combiner les approches ci-dessus de façon différente
selon les projets. Faites ce qui a le plus de sens pour vous et pour votre codebase.
Porter vos tests
La meilleure façon de vérifier que tout fonctionne quand vous avez porté votre code est
de tester votre code quand vous l’avez porté sur .NET. Pour cela, vous devez utiliser une
infrastructure de test qui génère et exécute des tests pour .NET. Vous avez actuellement
trois options :

xUnit
Prise en main
Outil pour convertir un projet MSTest en xUnit
NUnit
Prise en main
Billet de blog sur la migration de MSTest vers NUnit
MSTest

Approche recommandée
En définitive, le travail de portage dépend fortement de la structuration du code .NET
Framework. Il est recommandé de commencer par la base de la bibliothèque, qui
représente la composante essentielle du code. Il peut s’agir de modèles de données ou
d’autres classes et méthodes fondamentales utilisées directement ou indirectement par
tout le reste.

1. Portez le projet de test qui teste la couche en cours de portage de votre

bibliothèque.
2. Copiez la base de votre bibliothèque dans un nouveau projet .NET et sélectionnez
la version de .NET Standard que vous voulez prendre en charge.
3. Apportez les modifications nécessaires pour obtenir le code à compiler. Il est
possible que la plupart nécessitent l’ajout de dépendances de package NuGet à
votre fichier csproj.
4. Exécutez les tests et procédez aux ajustements nécessaires.
5. Sélectionnez la couche suivante de code à porter et répétez les étapes
précédentes.

Si vous commencez par la base de votre bibliothèque et que vous vous déplacez vers
l’extérieur en testant chaque couche au fur et à mesure, le portage devient un processus
systématique où les problèmes sont isolés sur une seule couche de code à la fois.

Étapes suivantes
Vue d’ensemble de l’Assistant Mise à niveau de .NET
Organiser votre projet pour prendre en charge à la fois le .NET Framework et .NET
Core
Organiser votre projet pour prendre en
charge .NET Framework et .NET
Article • 10/05/2023

Vous pouvez créer une solution qui se compile parallèlement pour .NET Framework et
.NET. Cet article décrit plusieurs options d’organisation de projet pour vous aider à
atteindre cet objectif. Voici quelques scénarios classiques à prendre en compte quand
vous devez décider comment configurer la disposition de votre projet avec .NET. La liste
peut ne pas couvrir tout ce que vous voulez.

Combiner des projets existants et des projets .NET en un seul projet

Avantages :
Simplifie votre processus de génération en compilant un seul projet au lieu de
plusieurs, chacun ciblant une version de .NET Framework ou une plateforme
différente.
Simplifie la gestion des fichiers sources pour les projets multiciblés, car vous
devez gérer un seul fichier projet. Lors de l’ajout ou de la suppression de fichiers
sources, les alternatives vous obligent à synchroniser manuellement ces fichiers
avec vos autres projets.
Générez facilement un package NuGet à consommer.
Vous permet d’écrire du code pour une version spécifique de .NET Framework à
l’aide de directives du compilateur.

Inconvénient :
nécessite que les développeurs utilisent Visual Studio 2019 ou une version
ultérieure pour ouvrir des projets existants. Pour prendre en charge les versions
antérieures de Visual Studio, conserver vos fichiers projet dans des dossiers
différents est une meilleure option.

Séparer tous les projets

Avantages :
Prend en charge le développement sur des projets existants pour les
développeurs et les contributeurs qui n’ont peut-être pas Visual Studio 2019 ou
une version ultérieure.
Réduit le risque de création de bogues dans des projets existants car aucune
évolution du code n’est nécessaire dans ces projets.

Prenons cet exemple de référentiel GitHub . La figure ci-dessous montre comment ce

référentiel est organisé :
Les sections suivantes décrivent plusieurs façons d’ajouter la prise en charge de .NET en
fonction de l’exemple de référentiel.

Remplacer des projets existants par un projet

.NET multiciblé
Réorganisez le référentiel de sorte que tous les fichiers *.csproj existants soient
supprimés et qu’un seul fichier *.csproj ciblant plusieurs frameworks soit créé. Il s’agit
d’une excellente option, car un seul projet peut être compilé pour différents frameworks.
Elle permet également de gérer différentes options de compilation et dépendances par
framework ciblé.

Pour obtenir un exemple de code, consultez GitHub .

Les modifications à noter sont :

Remplacement de packages.config et de *.csproj par un nouveau .NET *.csproj .

Les packages NuGet sont spécifiés avec <PackageReference> ItemGroup .
Conserver des projets existants et créer un
projet .NET
Si des projets existants ciblent des frameworks plus anciens, vous pouvez laisser ces
projets inchangés et utiliser un projet .NET pour cibler les futurs frameworks.

Pour obtenir un exemple de code, consultez GitHub .

Le projet .NET et les projets existants sont conservés dans des dossiers distincts.
Conserver les projets dans des dossiers distincts vous évite de devoir disposer de Visual
Studio 2019 ou d’une version ultérieure. Vous pouvez créer une solution distincte qui
ouvre seulement les anciens projets.

Voir aussi
Documentation sur le portage .NET
Migrer du .NET Framework Windows
Forms vers .NET
Article • 03/12/2024

Cet article explique comment mettre à niveau une application de bureau Windows
Forms vers .NET à l’aide de l’Assistant Mise à niveau .NET. Windows Forms reste une
infrastructure Windows uniquement, même si .NET est une technologie multiplateforme.

Prérequis
Système d’exploitation Windows.
Téléchargez et extrayez l’application de démonstration utilisée avec cet article.
Visual Studio 2022 version 17.12 ou ultérieure pour cibler .NET 9.
Extension De l’Assistant Mise à niveau .NET pour Visual Studio.

Évaluation
Vous devez analyser vos projets avant d’effectuer une mise à niveau. L’exécution d’une
analyse du code sur vos projets avec l’Assistant Mise à niveau .NET génère un rapport
auquel vous pouvez vous référer pour identifier les bloqueurs de migration potentiels.

Pour analyser vos projets et générer un rapport, cliquez avec le bouton droit sur le
fichier solution dans Explorateur de solutions, puis sélectionnez Mettre à niveau. Pour
plus d’informations sur l’exécution d’une analyse, consultez Analyser des projets avec
l’Assistant Mise à niveau .NET.

Migrer des dépendances

Si vous mettez à niveau plusieurs projets, commencez par des projets qui n’ont aucune
dépendance. Dans l’exemple De jeu correspondant, le projet MatchingGame dépend de
la bibliothèque MatchingGame.Logic . Par conséquent , MatchingGame.Logic doit
d’abord être mis à niveau.

 Conseil

Veillez à disposer d’une sauvegarde de votre code, par exemple dans le contrôle de
code source ou une copie.
Procédez comme suit pour mettre à niveau un projet dans Visual Studio :

1. Cliquez avec le bouton droit sur le projet MatchingGame.Logic dans la fenêtre

Explorateur de solutions, puis sélectionnez Mettre à niveau :

Un nouvel onglet est ouvert qui vous invite à choisir la mise à niveau que vous
souhaitez effectuer.

2. Sélectionnez Mise à niveau de projet sur place.

3. Ensuite, sélectionnez l’infrastructure cible.

En fonction du type de projet que vous mettez à niveau, vous disposez de

différentes options. .NET Standard 2.0 peut être utilisé par .NET Framework et
.NET. Il s’agit d’un bon choix si la bibliothèque ne s’appuie pas sur une technologie
de bureau comme Windows Forms, que ce projet fait.
 Sélectionnez .NET 9.0 , puis sélectionnez Suivant.

4. Une arborescence s’affiche avec tous les artefacts liés au projet, tels que les fichiers
de code et les bibliothèques. Vous pouvez mettre à niveau des artefacts individuels
ou l’ensemble du projet, qui est la valeur par défaut. Sélectionnez Mettre à niveau
la sélection pour démarrer la mise à niveau.

5. Une fois la mise à niveau terminée, les résultats sont affichés :

 Les artefacts avec un cercle vert unie ont été mis à niveau alors que les cercles
verts vides ont été ignorés. Les artefacts ignorés signifient que l’Assistant mise à
niveau n’a rien trouvé à mettre à niveau.

Maintenant que la bibliothèque de prise en charge de l’application est mise à niveau,

mettez à niveau l’application principale.

Remarques pour les projets Visual Basic

Actuellement, l’Assistant Mise à niveau .NET ne reconnaît pas l’utilisation du fichier de
System.Configuration paramètres créé par les modèles Visual Basic sur .NET Framework.

Il ne respecte pas également l’utilisation des extensions utilisées dans les My projets
.NET Framework, tels que My.Computer et My.User . Ces extensions ont été supprimées
dans .NET. En raison de ces deux problèmes, une bibliothèque Visual Basic ne sera pas
compilée après la migration avec l’Assistant Mise à niveau .NET.

Pour résoudre ce problème, le projet doit cibler Windows et référencer Windows Forms.

1. Une fois la migration terminée, double-cliquez sur le projet MatchingGame.Logic

dans la fenêtre Explorateur de solutions.
2. Recherchez l’élément <Project>/<PropertyGroup> .
3. Dans l’éditeur XML, remplacez la valeur par <TargetFramework> net9.0 net9.0-
windows .

4. Ajouter <UseWindowsForms>true</UseWindowsForms> à la ligne après

<TargetFramework> .

Les paramètres du projet doivent ressembler à l’extrait de code suivant :

 XML

<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net9.0-windows</TargetFramework>
<UseWindowsForms>true</UseWindowsForms>
<OutputType>Library</OutputType>
<MyType>Windows</MyType>

... other settings removed for brevity ...

Migrer le projet principal

Une fois que toutes les bibliothèques de prise en charge sont mises à niveau, le projet
d’application principal peut être mis à niveau. Avec l’exemple d’application, il n’existe
qu’un seul projet de bibliothèque à mettre à niveau, qui a été mis à niveau dans la
section précédente.

1. Cliquez avec le bouton droit sur le projet MatchingGame dans la fenêtre

Explorateur de solutions, puis sélectionnez Mettre à niveau :
2. Sélectionnez Mise à niveau de projet sur place.
3. Sélectionnez .NET 9.0 pour le framework cible, puis sélectionnez Suivant.
4. Laissez tous les artefacts sélectionnés et sélectionnez Mettre à niveau la sélection.

Une fois la mise à niveau terminée, les résultats sont affichés. Notez comment le projet
Windows Forms a un symbole d’avertissement. Développez cet élément et plus
d’informations s’affichent à propos de cette étape :
Notez que le composant de mise à niveau du projet mentionne que la police par défaut
a changé. Étant donné que la police peut affecter la disposition du contrôle, vous devez
vérifier chaque formulaire et contrôle personnalisé dans votre projet pour vous assurer
que l’interface utilisateur est correctement organisée.

Générer une build propre

Une fois votre projet principal mis à niveau, nettoyez et compilez-le.

1. Cliquez avec le bouton droit sur le projet MatchingGame dans la fenêtre

Explorateur de solutions, puis sélectionnez Nettoyer.
2. Cliquez avec le bouton droit sur le projet MatchingGame dans la fenêtre
Explorateur de solutions, puis sélectionnez Générer.

Si votre application a rencontré des erreurs, vous pouvez les trouver dans la fenêtre
Liste d’erreurs avec une recommandation pour les corriger.

L’exemple de projet de jeu correspondant Windows Forms est désormais mis à niveau
vers .NET 9.

Expérience post-mise à niveau

Si vous transférez une application de .NET Framework vers .NET, passez en revue la
modernisation après la mise à niveau vers .NET à partir de l’article .NET Framework .
Contenu connexe
Portage de .NET Framework vers .NET.

Le guide de portage 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. La
complexité de vos projets détermine la quantité de travail que vous allez effectuer
après la migration initiale des fichiers projet.

Moderniser après la mise à niveau vers .NET à partir de .NET Framework.

Le monde de .NET a beaucoup changé depuis .NET Framework. Ce lien fournit des
informations sur la modernisation de votre application après la mise à niveau.
Mise à niveau d’une application de
bureau WPF vers .NET 8
Article • 05/11/2024

Cet article explique comment mettre à niveau une application de bureau Windows
Presentation Foundation (WPF) vers .NET 8. Même si WPF s’exécute sur .NET, une
technologie multiplateforme, WPF est toujours un framework Windows uniquement. Les
types de projets wpF suivants peuvent être mis à niveau avec l’Assistant Mise à niveau
.NET :

Projet WPF
Bibliothèque de contrôles
Bibliothèque .NET

Si vous effectuez une mise à niveau de .NET Framework vers .NET, examinez l’article
Différences avec WPF .NET et le guide de portage de .NET Framework vers .NET .

Prérequis
Système d’exploitation Windows
Visual Studio 2022 version 17.7 ou ultérieure pour cibler .NET 8
Visual Studio 2022 version 17.1 ou ultérieure pour cibler .NET 7
Extension Assistant Mise à niveau .NET pour Visual Studio

Application de démonstration
Cet article a été écrit dans le contexte de la mise à niveau de l’exemple de projet Favoris
web, que vous pouvez télécharger à partir du dépôt GitHub d’exemples .NET.

Lancer la mise à niveau

Si vous mettez à niveau plusieurs projets, commencez par des projets qui n’ont aucune
dépendance. Dans l’exemple Favoris web, le projet WebSiteRatings dépend de la
bibliothèque StarVoteControl. StarVoteControl doit donc être mis à niveau en premier.

 Conseil
 Veillez à disposer d’une sauvegarde de votre code, par exemple dans le contrôle de
code source ou une copie.

Procédez comme suit pour mettre à niveau un projet dans Visual Studio :

1. Cliquez avec le bouton droit sur le projet StarVoteControl dans la fenêtre

Explorateur de solutions, puis sélectionnez Mettre à niveau :

Un nouvel onglet est ouvert qui vous invite à choisir la façon dont vous souhaitez
que la mise à niveau soit effectuée.

2. Sélectionnez Mise à niveau de projet sur place.

3. Ensuite, sélectionnez l’infrastructure cible. En fonction du type de projet que vous

mettez à niveau, différentes options sont présentées. .NET Standard 2.0 est un bon
choix si la bibliothèque ne s’appuie pas sur une technologie de bureau comme
WPF et peut être utilisée par les projets .NET Framework et les projets .NET.
Toutefois, les dernières versions de .NET fournissent de nombreuses améliorations
du langage et du compilateur sur .NET Standard.

Sélectionnez .NET 8.0 , puis sélectionnez Suivant.

4. Une arborescence s’affiche avec tous les artefacts liés au projet, tels que les fichiers
de code et les bibliothèques. Vous pouvez mettre à niveau des artefacts individuels
ou l’ensemble du projet, qui est la valeur par défaut. Sélectionnez Mettre à niveau
la sélection pour démarrer la mise à niveau.

Une fois la mise à niveau terminée, les résultats sont affichés :

 Les artefacts avec un cercle vert unie ont été mis à niveau alors que les cercles
verts vides ont été ignorés. Les artefacts ignorés signifient que l’Assistant mise à
niveau n’a rien trouvé à mettre à niveau.

Maintenant que la bibliothèque de prise en charge de l’application est mise à niveau,

mettez à niveau l’application principale.

Mettre à niveau l’application

Une fois que toutes les bibliothèques de prise en charge sont mises à niveau, le projet
d’application principal peut être mis à niveau. Appliquez la procédure suivante :

1. Cliquez avec le bouton droit sur le projet WebSiteRatings dans la fenêtre

Explorateur de solutions, puis sélectionnez Mettre à niveau :
2. Sélectionnez Mise à niveau du projet sur place comme mode de mise à niveau.
3. Sélectionnez .NET 8.0 pour le framework cible, puis sélectionnez Suivant.
4. Laissez tous les artefacts sélectionnés et sélectionnez Mettre à niveau la sélection.

Une fois la mise à niveau terminée, les résultats sont affichés. Si un élément a un
symbole d’avertissement, cela signifie qu’il existe une note à lire, que vous pouvez faire
en développant l’élément.

Générer une build propre

Une fois votre projet mis à niveau, propre et le compiler.
 1. Cliquez avec le bouton droit sur le projet WebSiteRatings dans la fenêtre
Explorateur de solutions, puis sélectionnez Nettoyer.
2. Cliquez avec le bouton droit sur le projet WebSiteRatings dans la fenêtre
Explorateur de solutions, puis sélectionnez Générer.

Si votre application a rencontré des erreurs, vous pouvez les trouver dans la fenêtre
Liste d’erreurs avec une recommandation pour les corriger.

Étapes post-mise à niveau

Si votre projet est mis à niveau de .NET Framework vers .NET, passez en revue les
informations de la modernisation après la mise à niveau vers .NET à partir de l’article
.NET Framework .

Après la mise à niveau, vous devez :

Vérifiez vos packages NuGet.

L’Assistant Mise à niveau .NET a mis à niveau certains packages vers de nouvelles
versions. Avec l’exemple d’application fourni dans cet article, le
Microsoft.Data.Sqlite package NuGet a été mis à niveau de 1.0.0 à 8.0.x.

Toutefois, la version 1.0.0 dépend du SQLite package NuGet, mais la version 8.0.x
supprime cette dépendance. Le SQLite package NuGet est toujours référencé par
le projet, même s’il n’est plus nécessaire. Les SQLite packages NuGet et
SQLite.Native NuGet peuvent être supprimés du projet.

Nettoyez les anciens packages NuGet.

Le fichier packages.config n’est plus nécessaire et peut être supprimé de votre

projet, car les références de package NuGet sont désormais déclarées dans le
fichier projet. En outre, le dossier de cache de package NuGet local, nommé
Packages, se trouve dans le dossier ou le dossier parent du projet. Ce dossier de
cache local peut être supprimé. Les nouvelles références de package NuGet
utilisent un dossier de cache global pour les packages, disponible dans le
répertoire de profil de l’utilisateur, nommé .nuget\packages.

Supprimez la System.Configuration bibliothèque.

La plupart des applications .NET Framework font référence à la

System.Configuration bibliothèque. Après la mise à niveau, il est possible que

cette bibliothèque soit toujours directement référencée.

 La System.Configuration bibliothèque utilise le fichier app.config pour fournir des
options de configuration au moment de l’exécution à votre application. Pour .NET,
cette bibliothèque a été remplacée par le
System.Configuration.ConfigurationManager package NuGet. Supprimez la

référence à la bibliothèque et ajoutez le package NuGet à votre projet.

Recherchez des emplacements pour moderniser votre application.

Les API et les bibliothèques ont changé un peu depuis la publication de .NET. Dans
la plupart des cas, .NET Framework n’a pas accès à ces améliorations. En effectuant
une mise à niveau vers .NET, vous avez désormais accès à des bibliothèques plus
modernes.

Les sections suivantes décrivent les zones que vous moderniserez l’exemple
d’application utilisé par cet article.

Moderniser : contrôle de navigateur Web

Le WebBrowser contrôle référencé par l’exemple d’application WPF est basé sur Internet
Explorer, qui est obsolète. WPF pour .NET peut utiliser le contrôle WebView2 basé sur
Microsoft Edge. Effectuez les étapes suivantes pour effectuer la mise à niveau vers le
nouveau WebView2 contrôle de navigateur Web :

1. Ajoutez le package NuGet Microsoft.Web.WebView2 .

2. Dans le fichier MainWindow.xaml :

a. Importez le contrôle dans l’espace de noms wpfControls dans l’élément racine :

XAML

<mah:MetroWindow x:Class="WebSiteRatings.MainWindow"

xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
xmlns:mc="http://schemas.openxmlformats.org/markup-
compatibility/2006"
xmlns:mah="clr-
namespace:MahApps.Metro.Controls;assembly=MahApps.Metro"
xmlns:local="clr-namespace:WebSiteRatings"
xmlns:vm="clr-namespace:WebSiteRatings.ViewModels"
xmlns:VoteControl="clr-
namespace:StarVoteControl;assembly=StarVoteControl"
xmlns:wpfControls="clr-
namespace:Microsoft.Web.WebView2.Wpf;assembly=Microsoft.Web.WebView2
.Wpf"
 Loaded="MetroWindow_Loaded"
mc:Ignorable="d"
Title="My Sites" Height="650" Width="1000">

b. Vers le bas où l’élément <Border> est déclaré, supprimez le WebBrowser contrôle

et remplacez-le par le wpfControls:WebView2 contrôle :

XAML

<Border Grid.Row="2" Grid.Column="1" Grid.ColumnSpan="2"

BorderThickness="1" BorderBrush="Black" Margin="5">
<wpfControls:WebView2 x:Name="browser"
ScrollViewer.CanContentScroll="True" />
</Border>

3. Modifiez le fichier de code arrière MainWindow.xaml.cs. Mettez à jour la

ListBox_SelectionChanged méthode pour définir la browser.Source propriété sur

un valide Uri. Ce code était précédemment passé dans l’URL du site Web sous la
forme d’une chaîne, mais le WebView2 contrôle nécessite un Uri .

C#

private void ListBox_SelectionChanged(object sender,

SelectionChangedEventArgs e)
{
var siteCollection = (ViewModels.SiteCollection)DataContext;

if (siteCollection.SelectedSite != null)
browser.Source = new Uri(siteCollection.SelectedSite.Url);
else
browser.NavigateToString("<body></body>");
}

Selon la version de Windows qu’un utilisateur de votre application exécute, il peut avoir
besoin d’installer le runtime WebView2. Pour plus d’informations, consultez Démarrage
de WebView2 dans les applications WPF.

Moderniser : appsettings.json
.NET Framework utilise le fichier App.config pour charger les paramètres de votre
application, tels que les chaînes de connexion et les fournisseurs de journalisation. .NET
utilise désormais le fichier appsettings.json pour les paramètres de l’application. Les
fichiers App.config sont pris en charge dans .NET via le
System.Configuration.ConfigurationManager package NuGet, et la prise en charge de

appsettings.json est fournie par le Microsoft.Extensions.Configuration package NuGet.

À mesure que d’autres bibliothèques sont mises à niveau vers .NET, elles se modernisent
en prenant en charge appsettings.json au lieu de App.config. Par exemple, les
fournisseurs de journalisation dans .NET Framework qui ont été mis à niveau pour
.NET 6+ n’utilisent plus App.config pour les paramètres. Il est bon de suivre leur direction
et de s’éloigner de l’utilisation d’App.config où vous pouvez.

Utiliser appsettings.json avec l’exemple d’application WPF

Par exemple, après la mise à niveau de l’exemple d’application WPF, utilisez
appsettings.json pour le chaîne de connexion vers la base de données locale.

1. Supprimez le System.Configuration.ConfigurationManager package NuGet.

2. Ajoutez le package NuGet Microsoft.Extensions.Configuration.Json .

3. Ajoutez un fichier au projet nommé appsettings.json.

4. Définissez le fichier appsettings.json à copier dans le répertoire de sortie.

Définissez la copie sur le paramètre de sortie via Visual Studio à l’aide de la

fenêtre Propriétés après avoir sélectionné le fichier dans le Explorateur de
solutions. Vous pouvez également modifier le projet directement et ajouter les
éléments suivants ItemGroup :

XML

<ItemGroup>
<Content Include="appsettings.json">
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</Content>
</ItemGroup>

5. Migrez les paramètres dans le fichier App.config vers un nouveau fichier

appsettings.json .

Dans l’exemple d’application WPF, app.config ne contenait qu’une seule chaîne de

connexion. Modifiez le fichier appsettings.json pour définir le chaîne de connexion :

JSON

{
"ConnectionStrings": {
 "database": "DataSource=sqlite.db;"
}
}

6. Modifiez le fichier App.xaml.cs , instanciant un objet de configuration qui charge le

fichier appsettings.json , les lignes ajoutées sont mises en surbrillance :

C#

using System.Windows;
using Microsoft.Extensions.Configuration;

namespace WebSiteRatings
{
/// <summary>
/// Interaction logic for App.xaml
/// </summary>
public partial class App : Application
{
public static IConfiguration Config { get; private set; }

public App()
{
Config = new ConfigurationBuilder()
.AddJsonFile("appsettings.json")
.Build();
}
}
}

7. Dans le fichier .\Models\Database.cs, modifiez la OpenConnection méthode pour

utiliser la nouvelle App.Config propriété. Cela nécessite l’importation de l’espace
Microsoft.Extensions.Configuration de noms :

C#

using Microsoft.Data.Sqlite;
using System.Collections.Generic;
using Microsoft.Extensions.Configuration;

namespace WebSiteRatings.Models
{
internal class Database
{
public static SqliteConnection OpenConnection() =>
new
SqliteConnection(App.Config.GetConnectionString("database"));

public static IEnumerable<Site> ReadSites()

GetConnectionString est une méthode d’extension fournie par l’espace de
Microsoft.Extensions.Configuration noms.
Comment déplacer un projet C++/CLI
vers .NET
Article • 05/02/2024

À compter de Visual Studio 2019, les projets C++/CLI peuvent cibler .NET. Cette prise en
charge permet de déplacer des applications de bureau Windows avec des couches
d’interopérabilité C++/CLI à partir de .NET Framework vers .NET. Cet article explique
comment déplacer des projets C++/CLI de .NET Framework vers .NET.

Limitations de C++/CLI .NET Core

Il existe certaines limitations importantes concernant les projets C++/CLI et .NET par
rapport à .NET Framework :

La compilation d’un projet C++/CLI sur un exécutable n’est pas prise en charge.
Vous devez compiler une DLL.
La prise en charge de C++/CLI pour .NET est réservée à Windows uniquement.
Les projets C++/CLI ne peuvent pas cibler .NET Standard.
Les projets C++/CLI ne prennent pas en charge le format de fichier projet plus
récent de style kit de développement logiciel (SDK). Au lieu de cela, les projets
C++/CLI utilisent le même format de fichier .vcxproj que les autres projets C++
Visual Studio.
Les projets C++/CLI ne peuvent pas cibler plusieurs plateformes .NET. Si vous
devez générer un projet C++/CLI pour .NET Framework et .NET, utilisez des fichiers
projet distincts.
.NET ne prend pas en charge la compilation de -clr:pure ou -clr:safe , seule
l’option -clr:netcore la plus récente (qui équivaut à -clr pour .NET Framework).

Porter un projet C++/CLI

Pour porter un projet C++/CLI vers .NET, apportez les modifications suivantes au fichier
.vcxproj. Ces étapes de migration diffèrent des étapes nécessaires pour d’autres types de
projets, car les projets C++/CLI n’utilisent pas de fichiers projet de style SDK.

1. Remplacez les propriétés <CLRSupport>true</CLRSupport> par

<CLRSupport>NetCore</CLRSupport> . Cette propriété se trouve souvent dans des

groupes de propriétés spécifiques à la configuration. Vous devrez peut-être la

remplacer à différents emplacements.
 2. Remplacez les propriétés <TargetFrameworkVersion> par
<TargetFramework>net8.0</TargetFramework> . Assurez-vous de modifier la balise et

la valeur.
3. Supprimez les références .NET Framework à System , System.Data ,
System.Windows.Forms et System.Xml , telles que <Reference Include="System" /> .

Les assemblys du kit de développement logiciel (SDK) .NET sont référencés

automatiquement lors de l’utilisation de <CLRSupport>NetCore</CLRSupport> .
4. Mettez à jour l’utilisation de l’API dans des fichiers .cpp, si nécessaire, pour
supprimer les API indisponibles dans .NET. Étant donné que les projets C++/CLI
ont tendance à être des couches d’interopérabilité assez minces, peu de
modifications sont souvent nécessaires. Vous pouvez utiliser l’analyseur de
portabilité .NET pour identifier les API .NET non prises en charge utilisées par les
fichiers binaires C++/CLI.
5. Si votre projet était un exécutable, procédez de la manière suivante :
a. Remplacez le type de projet par une bibliothèque.
b. Créez un projet exécutable .NET.
c. Dans le projet exécutable .NET, ajoutez la référence à la bibliothèque .NET
C++/CLI.

Utilisation de WPF et Windows Forms

Les projets .NET C++/CLI peuvent utiliser des API Windows Forms et WPF. Pour utiliser
ces API de bureau Windows, vous devez ajouter des références de framework explicites
aux bibliothèques d’interface utilisateur. Les projets de style SDK qui utilisent les API de
bureau Windows référencent automatiquement les bibliothèques de framework
nécessaires à l’aide du SDK Microsoft.NET.Sdk.WindowsDesktop . Étant donné que les
projets C++/CLI n’utilisent pas le format de projet de style SDK, ils doivent ajouter des
références d’infrastructure explicites lorsque .NET Core est ciblé.

Pour utiliser les API Windows Forms, ajoutez cette référence au fichier .vcxproj :

XML

<!-- Reference all of Windows Forms -->

<FrameworkReference Include="Microsoft.WindowsDesktop.App.WindowsForms" />

Pour utiliser les API WPF, ajoutez cette référence au fichier .vcxproj :

XML

<!-- Reference all of WPF -->

 <FrameworkReference Include="Microsoft.WindowsDesktop.App.WPF" />

Pour utiliser les API Windows Forms et WPF, ajoutez cette référence au fichier .vcxproj :

XML

<!-- Reference the entirety of the Windows desktop framework:

Windows Forms, WPF, and the types that provide integration between them
-->
<FrameworkReference Include="Microsoft.WindowsDesktop.App" />

Actuellement, il n’est pas possible d’ajouter ces références à l’aide du gestionnaire de

références de Visual Studio. Au lieu de cela, mettez à jour le fichier projet en le
modifiant manuellement. Dans Visual Studio, vous devez d’abord décharger le projet.
Vous pouvez également utiliser un autre éditeur comme Visual Studio Code.

Générer sans MSBuild

Il est également possible de générer des projets C++/CLI sans utiliser MSBuild. Procédez
comme suit pour générer un projet C++/CLI pour .NET Core directement avec cl.exe et
link.exe :

1. Lors de la compilation, passez -clr:netcore à cl.exe.

2. Référencez les assemblys de référence .NET nécessaires.

3. Lors de la liaison, indiquez le répertoire hôte de l’application .NET en tant que

LibPath (afin que ijwhost.lib puisse être trouvé).

4. Copiez ijwhost.dll (à partir du répertoire hôte de l’application .NET) dans le

répertoire de sortie du projet.

5. Assurez-vous qu’un fichier runtimeconfig.json existe pour le premier composant

de l’application qui va exécuter du code managé. Pour les dernières versions de
Visual Studio, un fichier runtime.config est créé et copié automatiquement.

Pour les versions antérieures de Visual Studio, si l’application a un point d’entrée

natif, vous devez créer manuellement le fichier runtimeconfig.json suivant de la
première bibliothèque C++/CLI pour utiliser le runtime .NET. Si une bibliothèque
C++/CLI est appelée depuis un point d’entrée managé, la bibliothèque n’a pas
besoin d’un fichier runtimeconfig.json, car l’assembly du point d’entrée en a un qui
est utilisé lors du démarrage du runtime.

JSON
 {
"runtimeOptions": {
"tfm": "net8.0",
"framework": {
"name": "Microsoft.NETCore.App",
"version": "8.0.0"
}
}
}

７ Notes

Les assemblys C++/CLI qui ciblent .NET 7 ou une version ultérieure sont toujours
chargés dans le AssemblyLoadContext par défaut. Toutefois, dans .NET 6 et
versions antérieures, les assemblies C++/CLI peuvent être chargés plusieurs fois,
chaque fois dans un nouveau AssemblyLoadContext . Si le code managé d’un
assembly C++/CLI est exécuté la première fois :

Depuis un appelant natif, l’assembly est chargé dans un AssemblyLoadContext

distinct.
Depuis un appelant managé, l’assembly est chargé dans le même
AssemblyLoadContext que l’appelant, généralement celui par défaut.

Pour toujours charger votre assembly C++/CLI dans le AssemblyLoadContext par

défaut, vous pouvez ajouter un appel de style « initialiser » depuis votre assembly
de point d’entrée à votre assembly C++/CLI. Pour plus d’informations, consultez ce
problème lié à dotnet/au runtime .

６ Collaborer avec nous sur Commentaires sur .NET

GitHub .NET est un projet open source.
La source de ce contenu se Sélectionnez un lien pour fournir des
trouve sur GitHub, où vous commentaires :
pouvez également créer et
examiner les problèmes et les  Ouvrir un problème de
demandes de tirage. Pour plus documentation
d’informations, consultez notre
guide du contributeur.  Indiquer des commentaires sur
le produit
Moderniser après la mise à niveau vers
.NET à partir de .NET Framework
Article • 31/01/2025

Dans cet article, vous allez découvrir différentes façons de moderniser votre application
après sa mise à niveau de .NET Framework vers .NET. Utilisez l’outil assistant de mise à
niveau .NET pour mettre à niveau votre application vers .NET.

API manquantes
Lors de la mise à niveau d’une application .NET Framework, vous aurez probablement
des incompatibilités. Cela est dû au fait que .NET Framework est une technologie
Windows uniquement et .NET est une technologie multiplateforme. Certaines
bibliothèques ne le sont pas ainsi. Par exemple, .NET ne fournit pas d’API prêtes à
l’emploi pour accéder au Registre Windows comme .NET Framework. La prise en charge
du Registre Windows est fournie par le package NuGet Microsoft.Win32.Registry . De
nombreuses bibliothèques spécifiques au .NET Framework ont été transférées vers .NET
ou .NET Standard et sont hébergées sur NuGet. Si vous trouvez une référence
manquante dans votre projet, recherchez NuGet.

Pack de compatibilité Windows

Si après la migration, vous avez des dépendances sur les API .NET Framework qui ne
sont pas prises en charge sur votre nouvelle version de .NET, vous pouvez les trouver
dans le package NuGet Microsoft.Windows.Compatibility . Il ajoute environ 20 000 API
à votre projet .NET, ce qui augmente considérablement l’ensemble d’API disponible
pour votre projet. Ces API incluent des API Windows uniquement telles que celles liées à
Windows Management Instrumentation (WMI) et à Windows EventLog. Pour plus
d’informations, consultez Utiliser le pack de compatibilité Windows pour porter le code
vers .NET.

Contrôle du navigateur web

Les projets qui ciblent une technologie de bureau Windows, telle que Windows
Presentation Foundation ou Windows Forms, peuvent inclure un contrôle de navigateur
web. Le contrôle de navigateur web fourni a probablement été conçu avant HTML5 et
d’autres technologies web modernes et est considéré comme obsolète. Microsoft publie
le package NuGet Microsoft.Web.WebView2 comme remplacement pour le contrôle
des navigateurs web modernes.

App.config
.NET Framework utilise le fichier App.config pour charger les paramètres de votre
application, tels que les chaînes de connexion et la configuration du fournisseur de
journalisation. Le fichier .NET moderne utilise le fichier appsettings.json pour les
paramètres de l’application. La version CLI de l’Assistant Mise à niveau gère la
conversion de fichiers App.config en appsettings.json, mais l’extension Visual Studio ne le
fait pas.

 Conseil

Si vous ne souhaitez pas utiliser le fichier appsettings.json, vous pouvez ajouter le

package NuGet System.Configuration.ConfigurationManager à votre application et
votre code compile et utilise le fichier App.config.

Même si appsettings.json est le moyen moderne de stocker et de récupérer les

paramètres et les chaînes de connexion, votre application a toujours du code qui utilise
le fichier App.config. Lorsque votre application a été migrée, le package NuGet
System.Configuration.ConfigurationManager a été ajouté au projet afin que votre code

utilisant le fichier App.config continue à être compilé.

À mesure que les bibliothèques sont mises à niveau vers .NET, elles se modernisent en
prenant en charge appsettings.json au lieu de App.config. Par exemple, les fournisseurs
de journalisation dans .NET Framework qui ont été mis à niveau pour .NET 6+ n’utilisent
plus App.config pour les paramètres. C’est bon pour vous de suivre leur direction et de
s’éloigner de l’utilisation de App.config.

La prise en charge de appsettings.json est fournie par le package NuGet

Microsoft.Extensions.Configuration .

Procédez comme suit pour utiliser le fichier appsettings.json en tant que fournisseur de
configuration :

1. Supprimez le paquet ou la bibliothèque NuGet

System.Configuration.ConfigurationManager si vous le référencez dans votre

application mise à niveau.

2. Ajoutez le package NuGet Microsoft.Extensions.Configuration.Json .

3. Créez un fichier nommé appsettings.json.
a. Cliquez avec le bouton droit sur le fichier projet dans Explorateur de solutions,
puis sélectionnez Ajouter>nouvel élément.
b. Dans la zone de recherche, insérez json .
c. Sélectionnez le modèle Fichier config JSON JavaScript et définissez le Nom sur
appsettings.json.
d. Appuyez sur Ajouter pour ajouter le nouveau fichier au projet.

4. Définissez le fichier appsettings.json à copier dans le répertoire de sortie.

Dans l'Explorateur de solutions, recherchez le fichier appsettings.json et définissez

les Propriétés suivantes :

Action de génération : Contenu

Copier dans le répertoire de sortie: toujours copier

5. Dans le code de démarrage de votre application, vous devez charger le fichier de

paramètres.

Le code de démarrage de votre application varie en fonction du type de projet. Par

exemple, une application WPF utilise le fichier App.xaml.cs pour la configuration
globale et une application Windows Forms utilise la méthode Program.Main pour le
démarrage. Peu importe, vous devez effectuer deux opérations au démarrage :

Créez un membre internal static ( Friend Shared en Visual Basic) accessible

depuis n’importe où dans votre application.
Au démarrage, affectez une instance à ce membre.

L’exemple suivant crée un membre nommé Config , l’affecte à une instance de la

méthode Main et charge une chaîne de connexion :

C#

using Microsoft.Extensions.Configuration;

internal class Program

{
internal static IConfiguration Config { get; private set; }

private static void Main(string[] args)

{
Config = new ConfigurationBuilder()
.AddJsonFile("appsettings.json")
.Build();

// Use the config file to get a connection string.

string? myConnectionString =
 Config.GetConnectionString("database");

// Run the rest of your app.

}
}

6. Mettez à jour le reste de votre code pour utiliser les nouvelles API de
configuration.

7. Supprimez le fichier App.config du projet.

Ｕ Attention

Assurez-vous que votre application s’exécute correctement sans le fichier

App.config. Sauvegardez le fichier App.config via le contrôle de code source ou
en copiant le fichier ailleurs. Une fois que vous avez soigneusement testé
votre application, supprimez le fichier App.config.