Avertissement: conflits trouvés entre différentes versions du même assembly dépendant

320

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

Le problème est que si j'inclus un composant externe, je reçois toujours l'avertissement suivant:

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

Que signifie exactement cet avertissement et y a-t-il une possibilité d'exclure cet avertissement (comme utiliser #pragma disable dans les fichiers de code source)?

ollifant
la source

Réponses:

410

Cet avertissement signifie que deux projets référencent le même assemblage (par exemple System.Windows.Forms) mais que 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 exemple, déplacez tous 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 elles ont été compilées.

  2. Ajoutez une 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 une erreur dans Visual Studio.

  3. Utilisez CopyLocal=true. Je ne sais pas si cela supprimera l'avertissement. Comme l'option 2 ci-dessus, cela signifie 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 disponible sur https://gist.github.com/1553265
  • Une autre méthode simple consiste à définir la verbosité de la sortie de génération (outils, options, projets et solutions, construire et exécuter, verbosité de sortie de construction de projet MSBuild, détaillée) et après la construction, recherchez l'avertissement dans la fenêtre de sortie et regardez le texte juste au-dessus. . (Pointe du chapeau à pauloya qui l'a suggéré dans les commentaires sur cette réponse) .
Brian Low
la source
9
Juste pour un moyen rapide de le trouver sans l'utilitaire - si vous ajoutez la redirection de liaison (comme option 2), il y montrera la ou les références impliquées - si vous le souhaitez, vous pouvez ensuite utiliser l'une des autres méthodes pour le gérer et supprimez la ou les redirection (s) de liaison de votre fichier de configuration.
Brisbe
222
La manière la plus simple de trouver quelles sont les «références incriminées» consiste à définir la verbosité de la sortie de la génération (Outils, Options, Projets et solutions, Générer et exécuter, verbosité de la sortie de la construction du projet MSBuild, détaillée) et après la construction, recherchez la fenêtre de sortie pour l'avertissement. Voir le texte juste au-dessus.
pauloya
7
La redirection de liaison en double-cliquant sur l'avertissement (étape 2) ne supprime pas mon avertissement. Je vois app.config ajouté avec l'assembly que je soupçonne être la cause, mais l'avertissement est toujours là après un nettoyage / reconstruction. Également essayé l'étape 3 en plus, pas de chance. Des idées?
angularsen
9
Et si ce ne sont pas des références de vos propres projets? Par exemple, j'ai référencé un projet, qui dépend de Newtonsoft.Json, Version = 6.0.0.0, et j'ai référencé un autre projet, qui a une dépendance de Newtonsoft.Json, Version = 4.5.0.0
Edward Ned Harvey
3
@ brian-low, puis-je suggérer d'ajouter le paramètre de verbosité de la sortie Build (comme suggéré dans le commentaire de @pauloya) comme option dans votre réponse aux côtés de l'utilitaire lié? (Avertissement, j'ai en fait essayé de modifier la réponse pour le faire, mais elle a été rejetée lors de la révision :))
Rick Riensche
44

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. Cela est plus susceptible de se produire si vos projets sont dans des solutions distinctes et peuvent donc être compilés séparément.

La façon dont je l'ai contourné est de définir Copier local sur Faux pour les références dans les projets d'assemblage. Ne le faites que pour les exécutables / applications Web où vous avez besoin de l'assemblage pour que le produit fini s'exécute.

J'espère que cela a du sens!

Matt Hamilton
la source
31

Je voulais poster la solution de pauloya qu'ils ont fournie dans les commentaires ci-dessus. Je pense que c'est la meilleure solution pour trouver les références incriminées.

La manière la plus simple de trouver quelles sont les «références incriminées» consiste à définir la verbosité de la sortie de la génération (Outils, Options, Projets et solutions, Générer et exécuter, verbosité de la sortie de la construction du projet MSBuild, détaillée) et après la construction, recherchez la fenêtre de sortie pour l'avertissement. 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 voir, il existe un conflit entre les versions 5 et 6 d'EF.

user1477388
la source
3
Mais maintenant que j'ai ces informations, comment puis-je supprimer l'erreur? Je peux voir quel est le conflit, mais je ne trouve pas où le projet fait référence à la version en conflit
Bassie
Salut @Bassie, la première chose à faire serait de vérifier le fichier de votre paquet de pépites et de déterminer si vous devez mettre à jour tous les fichiers vers la même version du paquet. Vous pouvez le faire en exécutant une commande similaire à update-package [your package name] -version 6.0.0 -reinstallma réponse ici stackoverflow.com/questions/22685530/…
user1477388
@Bassie, vous pouvez faire ce que l'avertissement suggère et ajouter la redirection de liaison au fichier app.config! (si la mise à jour n'est pas une option, c'est le cas.)
BrainSlugs83
@Bassie voir ma réponse, où je vous montre comment obtenir différents assemblys / .dll qui provoquent des problèmes de non-concordance.
newprint
22

J'ai eu le même problème avec l'un de mes projets, cependant, aucun des éléments 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'ai utilisé les versions correctes pour chaque projet dans la solution affectée, j'ai revérifié les entrées réelles dans chaque fichier de projet - rien n'y fait.

Finalement, il s'est avéré que le problème était une dépendance imbriquée d'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.

Gorgsenegger
la source
1
Même problème ici. Cependant, je n'ai aucune chance de mettre à jour la référence vers une version plus récente. J'ai essayé d'utiliser un App.config: alors qu'il fonctionne pour l'application, Visual Studio 2010 semble l'ignorer lors de la génération.
Thomas Weller
1
wow, j'ai eu ces problèmes pendant deux mois et je n'ai pas pu le localiser et le résoudre. Pour une raison quelconque, il se bloquerait uniquement pendant le débogage et dans certains cas, il remplacerait manuellement le .dll gênant par le vrai dans le dossier bin lorsque cela se produirait. Le débogage était une vraie douleur. Quand j'ai lu votre réponse, j'ai réalisé que c'était exactement ce qui m'arrivait et je l'ai corrigé en 5 minutes :)
Dennis Puzak
19

Sur Visual Studio, si vous cliquez avec le bouton droit sur la solution et Gérez les packages de nugets, un onglet "Consolider" définit tous les packages sur la même version.

Tiago Gouvêa
la source
Merci pour le conseil. Cela ne m'a pas aidé cette fois, mais c'est bon de savoir que c'est là.
BrainSlugs83
8

Je viens d'avoir ce message d'avertissement et j'ai nettoyé la solution et recompilé (Build -> Clean Solution) et c'est parti.

MoMo
la source
9
Seulement jusqu'à ce que vous reconstruisiez la solution
Luke
Cela me sauve! J'ai essayé une autre solution depuis hier mais celle-ci a résolu mon problème. Y compris le commentaire ci-dessus ^. Merci!
vnpnlz
6

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 à l'aide de Newtonsoft.Json 4.0

De:

<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>
Phil50
la source
C'était la solution pour moi. J'ai eu une redirection de liaison vers la version supérieure, et cela n'a fonctionné qu'une fois que je suis passé à la version inférieure.
mrwaim
1
Pourquoi? Si étrange pour moi. Je n'utilise pas EF, mais je pensais que nous voulons toujours passer à la dernière version?
Hoàng Long
1
@ HoàngLong parce que la version à laquelle vous faites référence est l'ancienne version, mais la version que vous incluez est la plus récente.
BrainSlugs83
3

J'ai une autre façon de le faire 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 ne sont pas 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 les packages Nuget»

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

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

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

  5. Faites-le pour tous vos projets.

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

Vous voudrez peut-être commencer par les projets inférieurs et progresser vers les niveaux supérieurs 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]

Facture
la source
2

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 porte le même nom et une version différente d'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 que vous avez une version différente du composant dans votre référentiel de code comme celle que vous avez installée sur la machine locale.

Essayez de trouver quels projets ont 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.

Jon Limjap
la source
2

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

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

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

cela a résolu mon problème. j'espère que cela vous aide aussi. Meilleures salutations.

Neelam Prajapati
la source
1

A également eu ce problème - dans mon cas, il était dû au fait que la propriété "Specific Version" sur un certain nombre de références était définie sur true. La modification de ce paramètre sur false sur ces références a résolu le problème.

Tristan Lewis
la source
1

Si j'utilisais NuGet, je n'avais qu'à faire:

  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 NuGet Package Manager au-dessus des sources de package

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

  5. Nettoyer et reconstruire et l'avertissement a disparu

Peasy facile

0tombo0
la source
1

Je viens de passer quelque temps à déboguer le même problème. Notez que ce problème peut ne pas être entre différents projets, mais en fait entre plusieurs références dans un projet qui dépendent de différentes versions de la même dll / assembly. Dans mon cas, le problème était une FastMember.dllincompatibilité des versions de référence provenant de deux packages NuGet différents dans un même projet. Quand on m'a donné un projet, il ne se compilait pas car les packages NuGet étaient manquants et VS refusait de restaurer les packages manquants. Grâce au menu NuGet, je mets à jour manuellement tous les NuGets vers la dernière version, c'est à ce moment que l'avertissement est apparu.

Dans Visual Studio Tools > Options > Build and Run > MSBuld Project build output verbosity: (set to) Diagnostics.Recherchez les lignes There was a conflict betweendans la Outputfenêtre. Voici la partie de la sortie que j'ai obtenue:

1>  There was a conflict between "FastMember, Version=1.5.0.0, Culture=neutral, PublicKeyToken=null" and "FastMember, Version=1.3.0.0, Culture=neutral, PublicKeyToken=null". (TaskId:19)
1>      "FastMember, Version=1.5.0.0, Culture=neutral, PublicKeyToken=null" was chosen because it was primary and "FastMember, Version=1.3.0.0, Culture=neutral, PublicKeyToken=null" was not. (TaskId:19)
1>      References which depend on "FastMember, Version=1.5.0.0, Culture=neutral, PublicKeyToken=null" [C:\Users\ksd3jvp\Source\Temp\AITool\Misra\AMSAITool\packages\FastMember.1.5.0\lib\net461\FastMember.dll]. (TaskId:19)
1>          C:\Users\ksd3jvp\Source\Temp\AITool\Misra\AMSAITool\packages\FastMember.1.5.0\lib\net461\FastMember.dll (TaskId:19)
1>            Project file item includes which caused reference "C:\Users\ksd3jvp\Source\Temp\AITool\Misra\AMSAITool\packages\FastMember.1.5.0\lib\net461\FastMember.dll". (TaskId:19)
1>              FastMember, Version=1.5.0.0, Culture=neutral, processorArchitecture=MSIL (TaskId:19)
1>      References which depend on "FastMember, Version=1.3.0.0, Culture=neutral, PublicKeyToken=null" []. (TaskId:19)
1>          C:\Users\ksd3jvp\Source\Temp\AITool\Misra\AMSAITool\packages\ClosedXML.0.94.2\lib\net46\ClosedXML.dll (TaskId:19)
1>            Project file item includes which caused reference "C:\Users\ksd3jvp\Source\Temp\AITool\Misra\AMSAITool\packages\ClosedXML.0.94.2\lib\net46\ClosedXML.dll". (TaskId:19)
1>              ClosedXML, Version=0.94.2.0, Culture=neutral, processorArchitecture=MSIL (TaskId:19)

Remarquerez que Project file item includes which caused reference "C:\Users\ksd3jvp\Source\Temp\AITool\Misra\AMSAITool\packages\ClosedXML.0.94.2\lib\net46\ClosedXML.dll"

ClosedXML.dllvient de ClosedXMLNuGet et cela dépend FastMember.dll 1.3.0.0. En plus de cela, il y a aussi FastMemberNuget dans le projet, et il l'a fait FastMember.dll 1.5.0.0. Décalage !

J'ai désinstallé ClosedXML& FastMemberNuGets, car j'avais une redirection de liaison et j'ai installé la dernière version de ClosedXMLThat qui a résolu le problème!

newprint
la source
0

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ée par un autre projet référencé). J'ai supprimé la solution de référence directe, nettoyée et reconstruite. Problème résolu.

Igor Gorjanc
la source
0
  1. Ouvrez "Explorateur de solutions".
  2. Cliquez sur "Afficher tous les fichiers"
  3. Développer "Références"
  4. Vous verrez une (ou plusieurs) référence (s) avec une icône légèrement différente des autres. En règle générale, c'est avec une boîte jaune vous suggérant d'en prendre note. Retirez-le.
  5. Ajoutez la référence et compilez votre code.
  6. C'est tout.

Dans mon cas, il y avait 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.

Sukhi
la source
0

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 arrêter le service et reconstruire la solution

Telwa Gangnam
la source
0

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 sur 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.

Dpedrinha
la source
0

J'ai eu un tel problème lorsque mon projet faisait référence à NETStandardLibrary et 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 avait disparu

Jacek Plesnar
la source
0

Voici la solution, style .NET Core 3.0: https://github.com/HTD/ref-check

Lorsque vous trouvez quels conflits, vous pourriez peut-être résoudre les conflits. Si les références en conflit proviennent d'autres packages, vous n'avez pas de chance ou vous devez utiliser des sources à la place.

Dans mon cas, les packages en conflit sont souvent les miens, je peux donc résoudre les problèmes de dépendance et les republier.

Harry
la source