Conflits trouvés entre différentes versions du même assembly dépendant qui n'ont pas pu être résolus


372

Lorsque je nettoie et puis crée ma solution qui a plusieurs projets, la fenêtre de sortie signale que la génération a réussi. Cependant, lorsque je visualise la fenêtre de la liste des erreurs , il me montre cet avertissement:

Conflits trouvés entre différentes versions du même assembly dépendant qui n'ont pas pu être résolus. Ces conflits de référence sont répertoriés dans le journal de génération lorsque la verbosité du journal est définie sur détaillée. C: \ Program Files (x86) \ MSBuild \ 12.0 \ bin \ Microsoft.Common.CurrentVersion.targets

Lorsque je double-cliquez sur ce message, il ouvre le fichier C: \ Program Files (x86) \ MSBuild \ 12.0 \ bin \ Microsoft.Common.CurrentVersion.targets mais je n'y comprends rien.

J'utilise Visual Studio Express 2013 pour le Web.

Comment savoir ce qui ne va pas et avec quelle DLL et comment puis-je faire disparaître l'avertissement?



2
J'ai soumis à MS Connect la suggestion d'inclure le nom de la DLL dans le message connect.microsoft.com/VisualStudio/feedback/details/2619450
Michael Freidgeim

Réponses:


513

eta: Il y a un article tueur sur ce genre de choses par le propre @Nick Craver de SO que vous devriez lire


Bien que les autres réponses le disent, elles ne le rendent pas explicite, alors je vais ...

Sur VS2013.2, pour déclencher réellement l'émission des informations citées, vous ne devez pas lire le message, qui dit:

C: \ Program Files (x86) \ MSBuild \ 12.0 \ bin \ Microsoft.Common.CurrentVersion.targets (1697,5): avertissement MSB3277: conflits trouvés entre différentes versions du même assembly dépendant qui n'ont pas pu être résolus. Ces conflits de référence sont répertoriés dans le journal de génération lorsque la verbosité du journal est définie sur détaillée .

C'est incorrect (ou du moins c'était pour certaines versions de Visual Studio - cela semble être OK sur une mise à jour VS2015 Update 3 ou ultérieure). Au lieu de cela, tournez-le vers Diagnostic (dans Outils-> Options-> Projet et solutions-> Générer et exécuter , définissez la verbosité de la sortie de la construction du projet MSBuild ), après quoi vous verrez des messages tels que:

Il y avait un conflit entre "Newtonsoft.Json, version = 6.0.0.0, Culture = neutre, PublicKeyToken = 30ad4fe6b2a6aeed" et "Newtonsoft.Json, version = 6.0.5.17707, Culture = neutre, PublicKeyToken = 30ad4fe6b2a6aeed".

  • "Newtonsoft.Json, Version = 6.0.0.0, Culture = neutral, PublicKeyToken = 30ad4fe6b2a6aeed" a été choisi car il était principal et "Newtonsoft.Json, Version = 6.0.5.17707, Culture = neutral, PublicKeyToken = 30ad4fe6b2a6aeed" ne l'était pas.

alors

  • Ctrl-Alt-O pour aller à la fenêtre de sortie Build
  • recherchez «a été choisi » pour trouver l'exploration.

... Et oui, pour ceux qui regardent le détail du message [diagnostic], c'était une nouvelle pour cet ignorant qu'il y a une convention en ville selon laquelle toutes les 6.xversions sont, en interne Assembly Version 6.0.0.0, c'est-à-dire que seul le composant SemVer Major entre dans l'Assemblée Version :)


3
Merci - utilisez Visual Studio depuis de nombreuses années et n'avez jamais eu de problème qui nécessitait de creuser aussi profondément dans le journal de construction. Problème différent mais en réalisant que les informations que je cherchais étaient émises quelque part, j'ai résolu mon problème.
Timothy Lee Russell,

4
Le niveau de journalisation détaillé semble fonctionner dans VS (donc aucun diagnostic requis). Ce ne serait pas la première fois que MSBuild se comporte différemment à l'intérieur de VS ....
Johannes Rudolph

105
Pour modifier la verbosité du journal dans le menu Outils-> Options, puis recherchez Projet et solutions-> Construire et exécuter
Jenn

3
Dans mon cas, j'ai eu trois conflits et l'un d'eux était responsable des deux autres. J'ai copié mon journal de construction "détaillé" dans le Bloc-notes, recherché "conflit", mis à jour le package NuGet pour la référence que j'ai reconnue et le problème a été résolu.
Isaac Lyman

@robotnik Merci pour la suggestion de modification [qui a été refusée par d'autres]. J'avais en fait inclus les informations au bas de la réponse mais j'espère que la réponse telle qu'elle est maintenant est aussi claire que vous le souhaitiez.
Ruben Bartelink

76

Exécutez msbuild Foo.sln /t:Rebuild /v:diag(à partir de C:\Program Files (x86)\MSBuild\12.0\bin) pour créer votre solution à partir de la ligne de commande et obtenir un peu plus de détails, puis recherchez celui .csproj.qui enregistre l'avertissement et vérifiez ses références et les références d'autres projets qui utilisent le même assembly commun qui diffère en version.

Modifier: Vous pouvez également définir la verbosité de la construction directement dans VS2013. Allez dans Tools> Optionsmenu puis allez dans Projects and Solutionset définissez la verbosité MSBuild sur Diagnostic.

Edit: Peu de clarifications car je viens d'en avoir un moi-même. Dans mon cas, l'avertissement était dû à l'ajout d'une référence à l'aide de l'invite Resharper par opposition à la boîte de dialogue Ajouter une référence, qui l'a fait sans version, même si les versions v4 et v12 sont disponibles.

<Reference Include="Microsoft.Build, Version=12.0.0.0, ..." />
<Reference Include="Microsoft.Build.Framework" />

contre

<Reference Include="Microsoft.Build, Version=12.0.0.0, ..." />
<Reference Include="Microsoft.Build.Framework, Version=12.0.0.0, ..." />

Dans le journal MSBuild avec /v:diagverbosité, il ressemblait à ce qui suit. en précisant quels sont les deux références en conflit: -

  There was a conflict between 
  "Microsoft.Build.Framework, Version=4.0.0.0, ..." and 
  "Microsoft.Build.Framework, Version=12.0.0.0, ...". (TaskId:16)

      "Microsoft.Build.Framework, Version=4.0.0.0, ..." was chosen because it was primary and 
      "Microsoft.Build.Framework, Version=12.0.0.0, ..." was not. (TaskId:16)

      References which depend on "Microsoft.Build.Framework, Version=4.0.0.0, ..." 
      [C:\...\v4.5.1\Microsoft.Build.Framework.dll]. (TaskId:16)

          C:\...\v4.5.1\Microsoft.Build.Framework.dll (TaskId:16)
            Project file item includes which caused reference "C:\...\v4.5.1\Microsoft.Build.Framework.dll". (TaskId:16)
              Microsoft.Build.Framework (TaskId:16)

      References which depend on "Microsoft.Build.Framework, Version=12.0.0.0, ..." 
      [C:\...\v12.0\Microsoft.Build.Framework.dll]. (TaskId:16)

          C:\...\v12.0\Microsoft.Build.dll (TaskId:16)
            Project file item includes which caused reference "C:\...\v12.0\Microsoft.Build.dll". (TaskId:16)
              Microsoft.Build, Version=12.0.0.0, ... (TaskId:16)

          C:\...\v12.0\Microsoft.Build.Engine.dll (TaskId:16)
            Project file item includes which caused reference "C:\...\v12.0\Microsoft.Build.Engine.dll". (TaskId:16)
              Microsoft.Build, Version=12.0.0.0, ... (TaskId:16)

C:\Program Files (x86)\MSBuild\12.0\bin\Microsoft.Common.CurrentVersion.targets(1697,5): warning MSB3277: 
Found conflicts between different versions of the same dependent assembly that could not be resolved.  
These reference conflicts are listed in the build log when log verbosity is set to detailed. 
[C:\Users\Ilya.Kozhevnikov\Dropbox\BuildTree\BuildTree\BuildTree.csproj]

10
J'ai fini par transférer cette commande dans un fichier journal, afin que je puisse y regarder plus facilement:msbuild "Foo.sln" /t:Rebuild /v:d > build.log
CrazyPyro

2
Le meilleur moyen de se rendre au terminal pour cela: stackoverflow.com/a/22702405/268066
CrazyPyro

@CrazyPyro msbuild a un tuyau "intégré" - /l:FileLogger,Microsoft.Build.Engine;logfile=build.log- notez les commutateurs pour l'explication des enregistreurs ici
drzaus

3
Où se trouve le "journal de build"? Comment le trouver?
Prisonnier ZERO

Cette réponse montre comment obtenir plus de détails de msbuild, ce qui est important pour un utilisateur mono. Toutes les autres réponses supposent que vous utilisez VS et que vous exécutez dans un environnement Windows.
UnconditionallyReinstateMonica

39

Je ne peux que soutenir la réponse de Ruben avec une comparaison entre les deux messages affichés:

entrez la description de l'image ici

et le message:

C: \ Program Files (x86) \ MSBuild \ 12.0 \ bin \ Microsoft.Common.CurrentVersion.targets (1697,5): avertissement MSB3277: conflits trouvés entre différentes versions du même assembly dépendant qui n'ont pas pu être résolus. Ces conflits de référence sont répertoriés dans le journal de génération lorsque la verbosité du journal est définie sur détaillée .

Donc, Ruben a raison - ce n'est tout simplement pas vrai. Il n'y a aucun conflit, juste une assemblée manquante. Cela est particulièrement ennuyeux lorsque le projet est une application ASP.NET, car les vues sont compilées à la demande , c'est-à-dire juste avant d'être affichées pour la première fois. C'est alors qu'il devient nécessaire de disposer de l'assemblage. (Il existe une option pour précompiler les vues avec le reste du code, mais c'est une autre histoire .) D'un autre côté, si vous définissez la verbosité sur Diagnostic, vous obtenez la sortie suivante:

C: \ Program Files (x86) \ MSBuild \ 12.0 \ bin \ Microsoft.Common.CurrentVersion.targets (1697,5): avertissement MSB3245: impossible de résoudre cette référence. Impossible de localiser l'assembly "System.Web.Razor, Version = 3.0.0.0, Culture = neutral, PublicKeyToken = 31bf3856ad364e35, processorArchitecture = MSIL". Vérifiez que l'assemblage existe sur le disque. Si cette référence est requise par votre code, vous pouvez obtenir des erreurs de compilation.

En conséquence, tout ce que vous devez faire est soit:

  1. Ajoutez une référence à l'assembly manuellement (localisez-la sur le disque, peut-être GAC, et ajoutez-la en tant que référence "directe"), ou
  2. Utilisez le package NuGet (s'il est publié dans la galerie) pour le télécharger et référencer l'assembly qu'il contient.

Plus d'informations sur la galerie NuGet ici . Plus d'informations sur la précompilation des vues ASP.NET ici .


Dans VS 2017, lorsque j'ai défini la «verbosité de sortie de la construction du projet MSBuild» (pas le fichier journal) sur Détaillé (pas de diagnostic), j'ai obtenu l'erreur «Impossible de localiser l'assembly» dans ma fenêtre de sortie.
ALEXintlsos

@ALEXintlsos: apparemment, cette fonctionnalité a changé; vous avez toujours l'erreur où qu'elle soit - suivez les instructions pour vous en débarrasser.
Alexander Christov

22

Changer la verbosité de la construction dans Visual Studio aidera à pointer dans la bonne direction. Suivez les étapes ci-dessous pour modifier la verbosité dans VS

  1. Allez dans Outils-> menu Options dans VS
  2. Projets et solutions ouverts-> Build and Run
  3. Modifiez la valeur de la verbosité de la sortie de génération du projet MSBuild. Choisissez l' un de Quiet, Minimal, Normal, DetailedetDiagnostic

Vérifiez la fenêtre de sortie ( Ctrl+ Alt+ O) dans VS pour voir les modifications dans le journal de génération.


16

et comment puis-je faire disparaître l'avertissement?

Vous devrez probablement réinstaller ou mettre à niveau vos packages NuGet pour résoudre ce problème.


2
Cela, avec une combinaison de redémarrage de Visual Studio lorsqu'il refusait de réinstaller un package correctement, a résolu le problème pour moi.
Ohad Schneider

22
Façon la plus simple de vérifier: Faites un clic droit sur la solution -> Manage NuGet packages for solution-> Sous Consolidatevous pouvez voir s'il existe différentes versions du même package a été installé
elshev

16

Réitérant l'un des commentaires de @elshev Cliquez avec le bouton droit sur la solution -> Gérer les packages NuGet pour la solution -> Sous Consolider, vous pouvez voir s'il existe différentes versions du même package installé. Mettez à jour les packages là-bas. L'erreur de conflit est résolue.


1
cela n'a pas résolu pour moi. J'ai dû désinstaller Newtonsoft.JSON et réinstaller via NuGet. Cette dépendances mises à jour sur les autres packages.
Garr Godfrey

Cela m'est également arrivé lors de l'utilisation d'outils tels que Resharper, qui ajoutent automatiquement des références manquantes de DLL. "Toujours ajouter en utilisant nuget" pourrait être une bonne suggestion ici.
Shaswat Rungta

Cela ne fonctionne pas pour moi car pour désinstaller un package, il tente une construction qui ne peut pas se produire car il y a un conflit de packages. Je ne suis donc même pas en mesure de réinstaller le package :(
nickornotto

8

J'utilise Visual Studio 2017 et je l'ai rencontré lorsque j'ai mis à jour certains packages Nuget. Ce qui a fonctionné pour moi, c'est d'ouvrir mon web.configfichier, de trouver le <runtime><assemblyBinding>nœud et de le supprimer. Enregistrez web.configet reconstruisez le projet.

Regardez la Error Listfenetre. Vous verrez ce qui ressemble à un long avertissement sur les conflits contraignants. Double-cliquez dessus et il recréera automatiquement le <runtime><assemblyBinding>bloc avec les mappages corrects.


6

Comme indiqué dans le point 6583 CLI dotnet, le problème doit être résolu avec la dotnet nuget locals --clear allcommande.


1
Cela n'a pas fonctionné pour moi; la situation était la même après l'exécution de la commande.
Zimano

3

Je pourrais résoudre cette installation de Newtonsoft Json dans le projet Web avec des packages de pépites


3

Évidemment, il y a beaucoup de causes différentes et donc beaucoup de solutions à ce problème. Pour jeter le mien dans le mélange, nous avons mis à niveau un assembly (System.Net.Http) qui était précédemment directement référencé dans notre projet Web vers une version gérée par NuGet. Cela a supprimé la référence directe dans ce projet, mais notre projet Test contenait toujours la référence directe. La mise à niveau des deux projets pour utiliser l'assembly géré par NuGet a résolu le problème.


2

Si vous avez apporté des modifications aux packages - rouvrez le sln. Cela a fonctionné pour moi!


1

J'ai constaté que, parfois, les packages nuget s'installent (ce que je suppose) .NET Core requis des composants ou d'autres éléments en conflit avec le cadre déjà installé. Ma solution était d'ouvrir le fichier de projet (.csproj) et de supprimer ces références. Par exemple, System.IO, System.Threading et autres, ont tendance à être ajoutés lorsque Microsoft.Bcl est inclus via un package NuGet récemment installé. Il n'y a aucune raison pour des versions spécifiques de celles-ci dans mes projets, donc je supprime les références et les versions du projet. J'espère que cela pourra aider.

Vous pouvez rechercher votre "référence" dans votre fichier de projet et supprimer les conflits. S'ils sont inclus dans System, débarrassez-vous d'eux et la construction devrait fonctionner. Cela peut ne pas répondre à tous les cas de ce problème - je m'assure que vous savez ce qui a fonctionné pour moi :)

Exemple de ce que j'ai commenté:

<!-- <Reference Include="System.Runtime, Version=2.6.9.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL"> -->
  <!-- <HintPath>$(SolutionDir)packages\Microsoft.Bcl.1.1.9\lib\net40\System.Runtime.dll</HintPath> -->
  <!-- <Private>True</Private> -->
<!-- </Reference> -->


1

J'ai suivi les conseils de plusieurs des réponses ici pour comprendre ce qui n'allait pas, mais aucune des réponses ne semblait expliquer comment y remédier. Mon problème était qu'une référence nécessitait une version différente d'une deuxième référence. Donc Newtonsoft était à la version 6, mais une autre DLL voulait 4.5. Ensuite, j'ai mis à jour Newtonsoft comme l'une des autres réponses suggérées et cela a aggravé les choses.

J'ai donc rétrogradé mon installation Newtonsoft et l'avertissement a disparu (VS 2017):

Cliquez avec le bouton droit sur Références dans l'explorateur de solutions et sélectionnez Gérer les packages NuGet ... Sous l'onglet "Installé", recherchez Newtonsoft (ou quel que soit votre conflit). Sur le côté droit, une liste déroulante apparaît à côté de "Version" que vous pouvez changer pour l'ancienne. versions. Il n'était pas évident pour moi que cette liste déroulante puisse être utilisée pour rétrograder.


1

Vous pouvez exécuter la CLI Dotnet avec une verbosité de diagnostic complète pour aider à trouver le problème.

dotnet run --verbosity diagnostic >> full_build.log

Une fois la construction terminée, vous pouvez rechercher l'erreur dans le fichier journal (full_build.log). La recherche d'un «conflit», par exemple, devrait vous amener directement au problème.


0

J'ai désinstallé Microsoft ASP.NET MVC nuget.org de gérer NuGet Packagaes et l'ai à nouveau réinstallé. Lors de sa réinstallation, il a résolu tous les conflits liés à la version du rasoir. Essayez-le.


0

J'ai changé la verbosité MSBuild en Diagnostic.Mais je n'ai pas pu trouver où était le problème, donc selon les réponses ci-dessus, j'avais ce code dans app.config:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
<configSections>
<section name="log4net" type="log4net.Config.Log4NetConfigurationSectionHandler, log4net" />
<sectionGroup name="userSettings" type="System.Configuration.UserSettingsGroup, System, Version=12.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
<section name="XbimXplorer.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" allowExeDefinition="MachineToLocalUser" requirePermission="false" />
</sectionGroup>
</configSections>
<startup>
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" />
</startup>

J'ai donc changé le premier système, la version 4.0.0.0 en 12.0.0.0 et mon projet a fonctionné.


0

Comme pour les autres réponses, définissez le niveau de journalisation de sortie sur détaillé et recherchez-y les conflits, qui vous indiqueront où chercher ensuite.

Dans mon cas, cela m'a envoyé dans quelques directions à la recherche de la source des références, mais à la fin, il s'est avéré que le problème était l'un de mes projets de bibliothèque de classe portable, il ciblait la mauvaise version et tirait la sienne version des références, d'où les conflits. Un nouveau ciblage rapide et le problème a été résolu.


0

Je viens de rencontrer ce problème et le problème après avoir basculé un package de nuget vers des DLL référencées localement. Le problème était lié à d'anciennes choses liées à l'exécution app.config.


0

J'ai eu cet avertissement après la migration vers la référence de package. Dans la sortie de diagnostic, il y avait des informations selon lesquelles la bibliothèque était référencée par la même bibliothèque elle-même. Il peut s'agir d'un bug de la nouvelle référence de package. La solution consistait à activer AutoGenerateBindingRedirects et à supprimer la redirection de liaison personnalisée.


0

VS 2017, projet MVC

Je ne sais pas pourquoi, mais pour moi, la solution à ce problème était de supprimer un outparamètre d'une signature de méthode de modèle appelée à partir de la méthode d'action du contrôleur. c'est un comportement très étrange mais c'était la solution à mon problème.


-2

Exécuter la Update-Packagecommande via la console du gestionnaire de packages

Cela corrigera MSB3277, ce qu'il fait, il réinstalle tous les packages et tous les assemblys associés avec lesquels ils sont livrés dans la version la plus élevée possible . Il est également possible de mettre à jour un package spécifique. Ou rétrograder après la mise à jour si vous le souhaitez, ce problème résolu pour moi à quelques reprises. Selon le nombre de packages de nuget dont vous disposez, ce processus peut prendre quelques minutes.

Plus d'informations sur les documents officiels https://docs.microsoft.com/en-us/nuget/consume-packages/reinstalling-and-updating-packages


14
Ces conseils peuvent gâcher votre journée si vous ne voulez pas les derniers packages, ce qui est souvent le cas pour le code de production.
Tony O'Hagan

1
Ceci est indiqué dans les conseils et ce qui pourrait être un problème pour vous, est un moyen sûr et facile de résoudre un problème, alors s'il vous plaît, ne votez pas en aval sur votre propre opinion.
Aistis Taraskevicius

1
Cette solution n'a pas fonctionné pour moi. J'avais déjà toutes les dernières versions.
Zero3

@ Zero3 l'avez-vous exécuté à partir de votre solution principale, sans spécifier directement de package, cela fonctionne généralement, car il réinstalle chacun d'eux et met à jour les références, ce qui provoque des correspondances erronées
Aistis Taraskevicius

3
C'est un conseil vraiment terrible. Ce n'est pas une opinion, la mise à jour des packages casse le code si ce n'est pas fait avec intention.
TheBatman
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.