web-dev-qa-db-fra.com

Problèmes de référence System. * Lors de l'introduction de la dépendance NETStandard.Library

Dans une grande solution avec 52 projets (tous nets462), la dernière version de certaines de nos dépendances est désormais uniquement conçue pour la norme NET. Par conséquent, ils dépendent du package NuGet NETStandard.Library qui à son tour traîne dans beaucoup d'autres versions 4.3.x de System.* packages qui se trouvent normalement dans le .NET Framework lui-même.

En conséquence, certains projets font référence à System.* bibliothèques du dossier packages, tandis que d'autres référencent System.* bibliothèques du .NET Framework.

Cela provoque le problème d'exécution bien connu, par exemple:

Message: System.IO.FileLoadException: impossible de charger le fichier ou l'assembly 'System.Net.Http, version = 4.1.1.2, Culture = neutre, PublicKeyToken = b03f5f7f11d50a3a' ou l'une de ses dépendances. La définition du manifeste de l'assembly localisé ne correspond pas à la référence de l'assembly. (Exception de HRESULT: 0x80131040)

Creuser dans les dépendances de NETStandard.Library packages, nous pouvons voir que le même problème existe également dans ces packages:

  • System.Collections. *
  • System.ComponentModel. *
  • System.Console
  • System.Globalization. *
  • System.IO. *
  • System.Linq. *
  • System.Net. *
  • System.ObjectModel
  • System.Reflection. *
  • System.Resources.ResourceManager
  • System.Runtime. *
  • System.Text. *
  • System.Threading. *
  • System.Xml. *

Normalement, cela est résolu en installant le même package dans les autres projets, mais nous avons affaire à beaucoup de projets et à beaucoup de packages ici et je ne veux pas ajouter aveuglément toutes ces dépendances aux 52 projets.

Cela m'a fait me demander si quelqu'un connaît un moyen facile de se remettre de cette situation et de faire en sorte que tous les projets référencent le package/DLL correct à partir du dossier des packages NuGet s'ils utilisent actuellement celui interne de NET Framework.

Une solution VS simple pour net462 et net471 démontrant le problème peut être trouvée ici

c#nugetvisual-studio-2017
32
huysentruitw

Dans le modèle de projet par défaut System.Net.Http est ajouté au projet en tant que référence et non en tant que package de nuget.

Dans vos deux solutions (4.6.1 et 4.7.1):

  • Le projet ClassLibrary dépend de System.Net.Http en tant que paquet nuget.

  • Projet ConsoleApp1 a une dépendance sur System.Net.Http comme simple référence à partir de .NET Framework

Ainsi, le problème n'est pas lié à la version de Framework cible.

Pour résoudre le problème, ajoutez la même version de System.Net.Http en tant que paquet nuget pour tous les projets (où il est utilisé).

  1. Cliquez avec le bouton droit sur la solution dans l'Explorateur de solutions et choisissez Manage NuGet Packages for Solution...

  2. Passer à l'onglet Installed

  3. Trouver System.Net.Http dans la liste, sélectionnez-le.

  4. Vérifier l'état actuel:

Initial state of references to System.Net.Http nuget package

  1. Installez le même version du paquet (4.3.0 dans votre cas) sur ConsoleApp1 projet.

  2. Vérifiez le résultat:

Fixed state of references to System.Net.Http nuget package

  1. Reconstruisez la solution.

Terminé.

Il est également recommandé de consolider les versions de package dans votre solution. Au lieu de cela, vous pourriez avoir des conflits de version pendant la construction. Ou, ce qui est pire, une erreur d'exécution comme MethodNotFound en raison de la redirection de liaison vers une autre version de la dépendance.

La raison du problème avec System.Net.Http est décrit ici: Broken System.Net.Http 4.1.1-4.3.0 post-mortem dans la section Comment éviter une telle situation à l'avenir? 2.1

En conséquence, nous avons identifié 2 packages OOB problématiques, qui ne sont pas des nœuds terminaux dans la plate-forme elle-même, et qui dépendent d'eux de la plate-forme - System.Net.Http et System.IO.Compression.

Cela signifie que le même System.Net.Http La bibliothèque est livrée dans .NET Framework et sous forme de package de nuget OOB (hors bande). Et certains paquets nuget pourraient en référencer la version nuget. Et voici le problème que j'ai décrit au tout début.

Vous n'avez donc pas à corriger les références à tous les System.* bibliothèques. Uniquement pour ces deux: System.Net.Http et System.IO.Compression.

11
Vladimir Serykh