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

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?

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

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]

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

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 .

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.

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.

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.

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.

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

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

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

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

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

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.

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.

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.

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

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.

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.

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.

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.

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