Analyser vos dépendances pour porter le code de .NET Framework vers .NET
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 :
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 :
- Ouvrez NuGet Package Explorer.
- Cliquez sur Open package from online feed.
- Recherchez le nom du package.
- Sélectionnez le nom du package dans les résultats de la recherche et cliquez sur Open.
- 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.You 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 :
<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 dotnet@microsoft.com 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 avec l’outil Assistant Mise à niveau .NET.
