Avertissement:Conflits détectés entre différentes versions du même assembly dépendant

StackOverflow https://stackoverflow.com/questions/17806

  •  09-06-2019
  •  | 
  •  

Question

Je développe actuellement une application .NET composée de 20 projets.Certains de ces projets sont compilés à l'aide de .NET 3.5, d'autres sont encore des projets .NET 2.0 (jusqu'à présent, aucun problème).

Le problème est que si j'inclus un composant externe, j'obtiens toujours l'avertissement suivant :

"Found conflicts between different versions of the same dependent assembly".

Que signifie exactement cet avertissement et existe-t-il une possibilité d'exclure cet avertissement (comme en utilisant #pragma Disable dans les fichiers de code source) ?

Était-ce utile?

La solution

Cet avertissement signifie que deux projets font référence au même assembly (par ex. System.Windows.Forms) mais les deux projets nécessitent des versions différentes.Vous avez quelques options:

  1. Recompilez tous les projets pour utiliser les mêmes versions (par ex.déplacer tout vers .Net 3.5).Il s'agit de l'option préférée car tout le code s'exécute avec les versions des dépendances avec lesquelles il a été compilé.

  2. Ajouter un redirection de liaison.Cela supprimera l'avertissement.Cependant, vos projets .Net 2.0 seront (au moment de l'exécution) liés aux versions .Net 3.5 des assemblys dépendants tels que System.Windows.Forms.Vous pouvez rapidement ajouter une redirection de liaison en double-cliquant sur l'erreur dans Visual Studio.

  3. Utiliser CopyLocal=true.Je ne sais pas si cela supprimera l'avertissement.Cela signifiera, comme l'option 2 ci-dessus, que tous les projets utiliseront la version .Net 3.5 de System.Windows.Forms.

Voici quelques façons d’identifier la ou les références incriminées :

  • Vous pouvez utiliser un utilitaire tel que celui trouvé surhttps://gist.github.com/1553265
  • Une autre méthode simple consiste à définir Build (Outils, Options, Projets et Solutions, Build et Solutions, Build et Solutions). Exécuter, Verbosité de sortie de build de projet MSBuild, Détaillé) et après building, recherchez l’avertissement dans la fenêtre de sortie et examinez le fichier texte juste au-dessus. (Pointe du chapeau à Pauloya qui l’a suggéré dans le commentaires sur cette réponse).

Autres conseils

Fondamentalement, cela se produit lorsque les assemblys auxquels vous faites référence ont "Copy Local" défini sur "True", ce qui signifie qu'une copie de la DLL est placée dans le dossier bin avec votre exe.

Étant donné que Visual Studio copiera également toutes les dépendances d’un assembly référencé, il est possible de se retrouver avec deux versions différentes du même assembly référencées.Cela est plus susceptible de se produire si vos projets se trouvent dans des solutions distinctes et peuvent donc être compilés séparément.

La façon dont je l'ai contourné consiste à définir Copy Local sur False pour les références dans les projets d'assemblage.Faites-le uniquement pour les exécutables/applications Web pour lesquels vous avez besoin de l'assembly pour que le produit fini s'exécute.

J'espère que cela a du sens !

Je voulais publier la solution de Pauloya fournie dans les commentaires ci-dessus.Je pense que c'est la meilleure solution pour retrouver les références incriminées.

La façon la plus simple de trouver quelles sont les « références incriminées » est de set Build output verbosity (Outils, Options, Projets et Solutions, Build and Run, Verbosité de sortie de build de projet MSBuild, Détaillée) et Après la génération, recherchez l’avertissement dans la fenêtre de sortie.Voir le texte juste au-dessus.

Par exemple, lorsque vous recherchez « conflit » dans le panneau de sortie, vous pouvez trouver quelque chose comme ceci :

3>  There was a conflict between "EntityFramework, Version=5.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" and "EntityFramework, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089".
3>      "EntityFramework, Version=5.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" was chosen because it was primary and "EntityFramework, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" was not.

Comme vous pouvez le constater, il existe un conflit entre les versions 5 et 6 d’EF.

J'ai eu le même problème avec l'un de mes projets, cependant, aucune des solutions ci-dessus n'a aidé à résoudre l'avertissement.J'ai vérifié le fichier journal de construction détaillé, j'ai utilisé AsmSpy pour vérifier que j'avais utilisé les versions correctes pour chaque projet dans la solution concernée, j'ai revérifié les entrées réelles dans chaque fichier de projet - rien n'y a aidé.

Finalement, il s'est avéré que le problème était une dépendance imbriquée de l'une des références que j'avais dans un projet.Cette référence (A) nécessitait à son tour une version différente de (B) qui était référencée directement à partir de tous les autres projets de ma solution.La mise à jour de la référence dans le projet référencé l'a résolu.

Solution A
+--Project A
   +--Reference A (version 1.1.0.0)
   +--Reference B
+--Project B
   +--Reference A (version 1.1.0.0)
   +--Reference B
   +--Reference C
+--Project C
   +--Reference X (this indirectly references Reference A, but with e.g. version 1.1.1.0)

Solution B
+--Project A
   +--Reference A (version 1.1.1.0)

J'espère que ce qui précède montre ce que je veux dire, il m'a fallu quelques heures pour le découvrir, alors j'espère que quelqu'un d'autre en bénéficiera également.

Sur Visual Studio si vous faites un clic droit sur le solution et Gérer les packages de nugets il y a un "Consolider" onglet qui définit tous les packages sur la même version.

Je viens de recevoir ce message d'avertissement, j'ai nettoyé la solution et recompilé (Build -> Clean Solution) et tout a disparu.

J'ai eu le même problème et j'ai résolu en modifiant ce qui suit dans web.config.

Cela m'est arrivé parce que j'exécute l'application en utilisant Newtonsoft.Json 4.0

Depuis:

<dependentAssembly>
  <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
  <bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="6.0.0.0" />
</dependentAssembly>

À:

<dependentAssembly>
  <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
  <bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="4.5.0.0" />
</dependentAssembly>

Cela dépend en fait de votre composant externe.Lorsque vous référencez un composant externe dans une application .NET, il génère un GUID pour identifier ce composant.Cette erreur se produit lorsque le composant externe référencé par l’un de vos projets a le même nom mais une version différente qu’un autre composant de ce type dans un autre assembly.

Cela se produit parfois lorsque vous utilisez « Parcourir » pour rechercher des références et ajouter la mauvaise version de l'assembly, ou lorsque vous disposez d'une version du composant dans votre référentiel de code différente de celle que vous avez installée sur la machine locale.

Essayez de trouver quels projets présentent ces conflits, supprimez les composants de la liste de référence, puis ajoutez-les à nouveau en vous assurant que vous pointez vers le même fichier.

J'ai une autre façon de procéder si vous utilisez Nuget pour gérer vos dépendances.J'ai découvert que parfois VS et Nuget ne correspondent pas et Nuget est incapable de reconnaître que vos projets sont désynchronisés.Le packages.config dira une chose mais le chemin indiqué dans Références - Propriétés indiquera autre chose.

Si vous souhaitez mettre à jour vos dépendances, procédez comme suit :

  1. Dans l’Explorateur de solutions, cliquez avec le bouton droit sur le projet et cliquez sur « Gérer » Packages Nuget'

  2. Sélectionnez l’onglet 'Paquets installés' dans le volet de gauche. paquets Vous voudrez peut-être copier votre fichier packages.config dans votre fichier bureau d’abord si vous en avez beaucoup, vous pouvez donc le vérifier avec Google pour voir quels paquets Nuget sont installés

  3. Désinstallez vos packages.C'est bon, nous allons les rajouter tout de suite.

  4. Installez immédiatement les packages dont vous avez besoin.Ce que Nuget fera non seulement vous fournira la dernière version, mais modifiera vos références et ajoutera également les redirections de liaison pour vous.

  5. Faites cela pour tous vos projets.

  6. Au niveau de la solution, effectuez un nettoyage et une reconstruction.

Vous souhaiterez peut-être commencer par les projets inférieurs, progresser vers ceux de niveau supérieur, et reconstruire chaque projet au fur et à mesure.

Si vous ne souhaitez pas mettre à jour vos dépendances, vous pouvez utiliser la console du gestionnaire de packages et utiliser la syntaxe Update-Package -ProjectName [yourProjectName] [packageName] -Version [versionNumber]

=> vérifiez qu'il y aura une instance d'application partiellement installée.

=> tout d'abord, désinstallez cette instance de l'application de désinstallation.

=> ensuite, nettoyez, reconstruisez et essayez de déployer.

cela a résolu mon problème. J'espère que cela vous aidera aussi.Cordialement.

J'ai également eu ce problème - dans mon cas, cela était dû au fait que la propriété "Version spécifique" sur un certain nombre de références était définie sur true.Changer cela en false sur ces références a résolu le problème.

Cela m'est arrivé aussi.Une DLL a été référencée deux fois :une fois directement (dans les références) et une fois indirectement (référencé par un autre projet référencé).J'ai supprimé la référence directe, nettoyé et reconstruit la solution.Problème résolu.

  1. Ouvrez "Explorateur de solutions".
  2. Cliquez sur "Afficher tous les fichiers"
  3. Développez "Références"
  4. Vous verrez une (ou plusieurs) référence(s) avec une icône légèrement différente des autres.Généralement, il s'agit d'un encadré jaune vous suggérant d'en prendre note.Supprimez-le simplement.
  5. Ajoutez la référence et compilez votre code.
  6. C'est tout.

Dans mon cas, il y a eu un problème avec la référence MySQL.D'une manière ou d'une autre, je pourrais en énumérer trois versions sous la liste de toutes les références disponibles ;pour .net 2.0, .net 4.0 et .net 4.5.J'ai suivi les processus 1 à 6 ci-dessus et cela a fonctionné pour moi.

Une autre chose à considérer et à vérifier est de vous assurer qu’aucun service en cours d’exécution n’utilise ce dossier bin.si c'est le cas, arrêtez le service et reconstruisez la solution

Il semble y avoir un problème sur Mac Visual Studio lors de la modification des fichiers .resx.Je ne sais pas vraiment ce qui s'est passé, mais j'ai eu ce problème dès que j'ai modifié certains fichiers .resx sur mon Mac.J'ai ouvert le projet sous Windows, ouvert les fichiers et ils étaient comme s'ils n'avaient pas été modifiés.Je les ai donc édités, enregistrés et tout a recommencé à fonctionner sur Mac également.

J'ai eu un tel problème lorsque mon projet faisait référence à NETStandardLibrary et que l'un des assemblys référencés était publié pour netcore.Je viens de le publier en tant que netstandard et le problème a disparu

Si j'utilisais NuGet, tout ce que j'avais à faire était :

  1. cliquez avec le bouton droit sur le projet et cliquez sur Gérer les packages NuGet.

  2. cliquez sur le rouage en haut à droite

  3. cliquez sur l'onglet Général dans le gestionnaire de packages NuGet au-dessus des sources du package

  4. cochez "Ignorer l'application des redirections de liaison" dans Redirections de liaison

  5. Nettoyer et reconstruire et l'avertissement a disparu

Très facile

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top