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

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)?

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

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!

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.

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.

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.

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

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>

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]

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.

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

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.

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

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!

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.

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.

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

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.

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

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.