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


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



Answers


Cet avertissement signifie que deux projets référencent le même assembly (par exemple, System.Windows.Forms ) mais que les deux projets requièrent 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). C'est l'option préférée car tout le code est exécuté avec les versions des dépendances avec lesquelles ils ont été compilés.

  2. Ajouter une redirection de liaison . Cela supprimera l'avertissement. Cependant, vos projets .Net 2.0 seront (lors 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 suis pas sûr 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 un utilitaire pour identifier la ou les références incriminées:

https://gist.github.com/1553265




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!




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

Le moyen le plus simple de trouver ce qu'est la "référence (s) fautive" est de définir la verbosité de sortie de construction (Outils, Options, Projets et Solutions, Construire et Exécuter, MSBuild projet build verbosity, Detailed) et après construction, recherche 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 EF 5 et 6.




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 juste eu 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 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>



Sur Visual Studio, si vous cliquez avec le bouton droit de la souris sur la solution et Gérer les paquets de nuget, il y a un onglet "Consolider" qui définit tous les paquets sur la même version.




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.




J'ai un autre moyen 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 sont désynchronisés. Le fichier packages.config dira une chose mais le chemin indiqué dans References - Properties indiquera autre chose.

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

  1. À partir de l'Explorateur de solutions, cliquez avec le bouton droit sur le Projet et cliquez sur "Gérer les paquets de Nuget"

  2. Sélectionnez l'onglet 'Packages installés' dans le volet de gauche Enregistrez vos paquets installés Vous pouvez d'abord copier votre fichier packages.config sur votre bureau si vous en avez beaucoup, vous pouvez donc vérifier avec Google pour voir quels sont les paquets Nuget installés

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

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

  5. Faites ceci pour tous vos projets.

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

Vous voudrez peut-être commencer par les projets les plus bas et vous frayer un chemin vers les projets de plus haut niveau, 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 [votreNomProjet] [nom_package] -Version [numéro_version]




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




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

=> désinstallez d'abord 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 aidera aussi. Meilleures salutations.




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.




  1. Ouvrez "Solution Explorer".
  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. Typiquement, c'est avec une boîte jaune qui vous suggère 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 certaine manière, je pourrais en lister 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 le processus 1 à 6 ci-dessus et cela a fonctionné pour moi.




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