Partage via


Avertissement NuGet NU1605

Exemple 1

Passage à la version antérieure du package détecté : « PackageB » de 4.0.0 à 3.5.0. Référencez le package directement à partir du projet pour sélectionner une autre version.
    « Project » -> « PackageA » 4.0.0 -> « PackageB » (>= 4.0.0)
    « Project » -> « PackageB » (>= 3.5.0)

Problème

Un package de dépendances a spécifié une contrainte de version sur une version supérieure d’un package que la restauration finalement résolue. Cela est dû à la règle direct-dependency-wins : lors de la résolution des packages, la version du package direct dans le sous-graphique remplace celle des packages distants avec le même ID.

Solution

Pour le projet présentant l’avertissement de restauration, ajoutez une référence de package à la version supérieure du package.

Dans l’exemple ci-dessus, vous devez remplacer la référence du package par PackageB 4.0.0 :

« PackageA » 4.0.0 -> « PackageB » 4.0.0
« PackageB » 4.0.0

Exemple 2

Passage à la version antérieure du package détecté : « PackageC » de 2.0.0 à 1.1.0. Référencez le package directement à partir du projet pour sélectionner une autre version.
    « Project » -> « PackageA » 1.0.0 -> « PackageB » 2.0.0 ->« PackageC » (>= 2.0.0)
    « Project » -> « PackageA » 1.0.0 -> « PackageC » (>= 1.1.0)

Problème

Un package de dépendances a spécifié une contrainte de version sur une version supérieure d’un package que la restauration finalement résolue. Cela est dû à la règle direct-dependency-wins : lors de la résolution des packages, NuGet tente d’honorer l’intention de l’auteur du package. L’auteur est PackageA explicitement passé de la version PackageC 1.1.0 à la version PackageC 2.0.0.

Solution

Pour le projet présentant l’avertissement de restauration, ajoutez une référence de package à la version supérieure du package.

Dans l’exemple ci-dessus, vous devez remplacer la référence du package par PackageC 2.0.0 :

« PackageA » 4.0.0 -> « PackageB » 4.0.0
« PackageB » 4.0.0

Exemple 3

Rétrogradation du package détectée : System.IO.FileSystem.Primitives de 4.3.0 à 4.0.1. Référencez le package directement à partir du projet pour sélectionner une autre version.
Projet -> System.IO.FileSystem 4.0.1 -> runtime.win.System.IO.FileSystem 4.3.0 -> System.IO.FileSystem.Primitives (>= 4.3.0)
Projet -> System.IO.FileSystem 4.0.1 -> System.IO.FileSystem.Primitives (>= 4.0.1)

Problème

Certaines combinaisons de packages fournis avec .NET Core 1.0 et 1.1 ne sont pas compatibles les unes avec les autres lorsqu’ils sont référencés ensemble dans un projet .NET Core 3.0 ou ultérieur, et qu’un RuntimeIdentifier est spécifié. Les packages problématiques commencent généralement par System. ou Microsoft. et ont des numéros de version compris entre 4.0.0 et 4.3.1. Dans ce cas, le message de passage à une version antérieure aura un package commençant par runtime.<RID> dans la chaîne de dépendances.

Solution

Pour contourner ce problème, ajoutez le PackageReference suivant :

<PackageReference Include="Microsoft.NETCore.Targets" Version="3.0.0" PrivateAssets="all" />

Vous pouvez choisir d’utiliser la mise en correspondance version de la version principale de votre kit de développement logiciel (SDK).

Exemple 4

Passage à la version antérieure du package détecté : Microsoft.NETCore.App de 2.1.8 à 2.1.0. Référencez le package directement à partir du projet pour sélectionner une autre version.
    test -> mvc -> Microsoft.NETCore.App (>= 2.1.8)
    test -> Microsoft.NETCore.App (>= 2.1.0)

Problème

Le projet mvc a spécifié une contrainte de version sur une version supérieure d’un package que la restauration finalement résolue. Cela est dû à la règle direct-dependency-wins : lors de la résolution des packages, la version du package référencé directement dans le graphique remplace celle du package distant avec le même ID.

Solution

Cette erreur spécifique (avec Microsoft.NETCore.App package) est améliorée en déplaçant votre SDK .NET Core vers la version 2.2.100 ou ultérieure. Microsoft.NETCore.App est un package référencé automatiquement que le kit de développement logiciel (SDK) .NET Core avant la version 3.0.100 choisit d’intégrer automatiquement. Voir également Restauration par progression du runtime de déploiement autonome.

Remarque

Bien que NU1605 soit considéré comme un avertissement par l’outil NuGet, le kit de développement logiciel (SDK) .NET choisit de traiter cet avertissement comme une erreur via WarningsAsErrors. Votre projet peut mettre à niveau cet avertissement vers une erreur en définissant TreatWarningsAsErrors sur true. Bien qu’il ne soit pas recommandé, du fait que vous êtes plus susceptible de rencontrer des problèmes d’exécution, vous pouvez choisir de supprimer cet avertissement.

Conseil

Solution alternative : NuGetSolver est une extension Visual Studio développée par Microsoft DevLabs, conçue pour faciliter la résolution des conflits de dépendances. Il automatise le processus d’identification et de résolution de ces problèmes. Pour plus d’informations, visitez la page NuGetSolver sur visual Studio Marketplace et nous aimerions entendre vos commentaires sur votre expérience.