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


Answers

Fondamentalement, cela se produit lorsque les assemblys que vous référencez 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.

Comme Visual Studio copiera également toutes les dépendances d'un assemblage référencé, il est possible de se retrouver avec deux versions différentes du même assemblage auquel il est fait référence. Ceci est plus susceptible de se produire si vos projets sont dans des solutions séparées, et peuvent donc être compilés séparément.

La façon dont je l'ai fait est de mettre Copy Local à False pour les références dans les projets d'assemblage. Ne le faites que pour les exécutables / applications Web pour lesquels vous avez besoin de l'assemblage du produit fini.

J'espère que cela a du sens!

Question

Je développe actuellement une application .NET, qui comprend 20 projets. Certains de ces projets sont compilés en utilisant .NET 3.5, d'autres sont encore des projets .NET 2.0 (jusqu'à présent, pas de 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 existe-t-il une possibilité d'exclure cet avertissement (comme l'utilisation de #pragma disable dans les fichiers de code source)?




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 détaillé de construction, j'ai utilisé AsmSpy pour vérifier que j'ai utilisé les versions correctes pour chaque projet dans la solution affectée, j'ai vérifié les entrées réelles dans chaque fichier de projet - rien n'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) à son tour nécessitait 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, a pris mes quelques heures pour le savoir, alors j'espère que quelqu'un d'autre va bénéficier aussi.




J'ai eu le même problème et j'ai résolu en changeant le suivant dans web.config.

Cela m'est arrivé parce que je cours l'application en utilisant 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>



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 et une version différente qu'un autre composant d'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 les projets qui ont ces conflits, supprimez les composants de la liste de référence, puis ajoutez-les à nouveau en vous assurant que vous pointez sur le même fichier.




Également eu ce problème - dans mon cas, il a été provoqué par avoir la propriété "Version Spécifique" sur un certain nombre de références définies sur true. Changer ceci 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ée par un autre projet référencé). J'ai enlevé la référence directe, la solution nettoyée et reconstruite. Problème résolu.




Une autre chose à considérer et vérifier est, assurez-vous que vous n'avez aucun service en cours d'exécution qui utilise ce dossier bin. si leur est d'arrêter le service et la solution de reconstruction