35 votes

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 net462), la version la plus récente de certains de nos dépendances sont maintenant créés uniquement pour NET standard. Par conséquent, ils dépendent du package NuGet NETStandard.Library qui traîne dans beaucoup d'autres 4.3.x version d' System.* des paquets qui sont normalement dans le .NET Framework lui-même.

Comme un résultat, certains projets de référence System.* des bibliothèques dans le dossier packages, tandis que d'autres référence System.* des bibliothèques de la .NET Framework.

Cela provoque bien connu de l'exécution problème, f.e.:

Message: Système.IO.FileLoadException : impossible de charger le fichier ou l'assembly 'Système.Net.Http, Version=4.1.1.2, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' ou une de ses dépendances. L'assemblée manifeste définition ne correspond pas à la référence d'assembly. (Exception de HRESULT: 0x80131040)

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

  • Système.Les Collections.*
  • Système.ComponentModel.*
  • Système.Console
  • Système.De la mondialisation.*
  • Système.IO.*
  • Système.Linq.*
  • System.Net.*
  • Système.ObjectModel
  • Système.De la réflexion.*
  • Système.Les ressources.ResourceManager
  • Système.Moment de l'exécution.*
  • Système.De texte.*
  • Système.Le filetage.*
  • System.Xml.*

Normalement c'est résolu en installant le même paquet dans les autres projets, mais nous avons affaire à un grand nombre de projets et beaucoup de paquets et je ne veux pas aveuglément ajouter toutes ces dépendances à l'ensemble des 52 projets.

Cela m'a fait me demander si quelqu'un connaît un moyen facile de se sortir de cette situation et de rendre tous les projets de référence le bon forfait/DLL dans le dossier packages NuGet si ils utilisent le NET Framework interne.

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

12voto

Vladimir Serykh Points 1933

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

Dans les deux solutions (4.6.1 et 4.7.1):

  • Projet ClassLibrary a une dépendance sur l' System.Net.Http comme un package nuget.

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

Donc, le problème n'est pas lié à la Cible Framework version.

Pour résoudre ce problème, ajoutez la même version de l' System.Net.Http comme un package nuget pour tous les projets (où il est utilisé).

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

  2. Commutateur Installed onglet

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

  4. Vérifier l'état actuel:

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

  1. Installez la même version du paquet (4.3.0 dans votre cas) à l' ConsoleApp1 du projet.

  2. Vérifiez le résultat:

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

  1. Reconstruire la solution.

Fait.


Aussi, c'est bien pratique d'avoir les versions de package consolidé dans votre solution. Au lieu de cela, vous pourriez avoir des conflits de version lors de la construction. Ou, ce qui est pire, des erreurs d'exécution comme MethodNotFound en raison de la liaison de rediriger vers une autre version de la dépendance.


La raison pour le problème de l' System.Net.Http est décrit ici: Système Cassé.Net.Http 4.1.1-4.3.0 post-mortem dans la section Comment éviter qu'une telle situation à l'avenir? 2.1

En conséquence, nous avons identifié 2 problématique OOB paquets, qui ne sont pas des feuilles-les nœuds de la plate-forme elle-même, et de dépendance à partir de la plate-forme sur leur Système.Net.Http et du Système.IO.La Compression.

Cela signifie que le même System.Net.Http bibliothèque est expédiée dans .NET Framework et que des OOB (out-of-band) package nuget. Et certains packages nuget pourraient référence nuget version de celui-ci. Et ici, il s'agit le problème que j'ai décrit au début.

Donc, vous n'avez pas de fixer les références à tous System.* des bibliothèques. Seulement pour ces deux: System.Net.Http et System.IO.Compression.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X