发现了不同版本的相同依赖程序集之间的冲突,无法解决。

431
当我清理并构建一个包含多个项目的解决方案时,输出窗口报告构建成功。但是,当我查看错误列表窗口时,它显示了以下警告:

找到无法解决的同一依赖程序集的不同版本之间的冲突。当日志详细度设置为详细时,在构建日志中列出这些引用冲突。 C:\Program Files (x86)\MSBuild\12.0\bin\Microsoft.Common.CurrentVersion.targets

当我双击此消息时,它会打开C:\ Program Files(x86)\ MSBuild \ 12.0 \ bin \ Microsoft.Common.CurrentVersion.targets文件,但我不理解其中任何内容。
我正在使用Visual Studio Express 2013 for the Web。
我该如何找出问题所在以及哪个DLL出现了问题?如何消除警告?

2
还可以参考... https://dev59.com/TnI-5IYBdhLWcg3wZ3jC - SteveC
4
我已向MS Connect提交了建议,希望在消息中包括DLL名称。 https://connect.microsoft.com/VisualStudio/feedback/details/2619450 - Michael Freidgeim
我的情况是由于项目A中的<PrivateAssets>引起的。它将其他依赖项(我们称其为包X)的版本提升到了更高的版本。解决方案还有项目B,它将项目A作为引用。它看到包X的“低版本”(并选择该版本作为“主要”版本),因为私有资产请求的更高版本是...嗯,私有的-不可见的。现在到了构建的时候:PackageX.dll“低版本”被复制到输出,程序集projectA.dll被复制到输出... 等等! projectA.dll需要projekt X“更高版本”->无法解决的DLL地狱->构建失败。 - AnorZaken
22个回答

563

注:SO的Nick Craver撰写了一篇绝妙的文章,你应该去读一下。


虽然其他答案也说了这个问题,但它们没有明确说明,所以我会...

在VS2013.2中,要实际触发引用冲突信息的输出,你需要不要阅读消息,消息如下:

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.

这是错误的(或者至少对于某些版本的Visual Studio来说是错误的——在更新的VS2015 Update 3或更高版本上似乎没问题)。而应该将其设置为诊断级别(从“工具 -> 选项 -> 项目和解决方案 ->构建和运行”,设置“MSBuild项目生成输出详细程度”),然后你会看到以下类似的消息:

"Newtonsoft.Json,版本=6.0.0.0,Culture=neutral,PublicKeyToken=30ad4fe6b2a6aeed"与"Newtonsoft.Json, Version=6.0.5.17707, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed"之间存在冲突。

  • 因为它是主要的,“Newtonsoft.Json,版本=6.0.0.0,Culture=neutral,PublicKeyToken=30ad4fe6b2a6aeed”被选择了,而“Newtonsoft.Json,版本=6.0.5.17707,Culture=neutral,PublicKeyToken=30ad4fe6b2a6aeed”没有被选择。

然后:

  • Ctrl-Alt-O 按键可进入构建输出窗口
  • 搜索“was chosen”以查找钻取结果。

......是的,对于那些查看[诊断]消息细节的人来说,这个无知的人很惊讶地发现镇上有一种约定俗成的方法,即所有版本为6.x的内部程序集版本都为6.0.0.0,也就是说,只有SemVer Major组件进入了程序集版本 :)


3
谢谢 - 我已经使用Visual Studio很多年了,从来没有遇到需要深入构建日志进行挖掘的问题。虽然问题不同,但意识到我所寻找的信息正在某个地方被输出解决了我的问题。 - Timothy Lee Russell
4
日志详细级别在Visual Studio中似乎可以工作(因此不需要诊断)。虽然这不是MSBuild在Visual Studio内部表现不同的第一次。 - Johannes Rudolph
123
从菜单“工具->选项”中更改日志详细程度,然后找到“项目和解决方案->生成和运行”。 - Jenn
3
就我而言,我遇到了三个冲突,其中一个冲突导致了另外两个冲突。我将我的“详细”构建日志复制到记事本中,搜索“conflict”,更新了我认出的NuGet包引用,并解决了问题。 - Isaac Lyman
2
这个答案实际上解释了如何修复它吗? - Andrew
显示剩余3条评论

79
运行msbuild Foo.sln /t:Rebuild /v:diag(从C:\Program Files (x86)\MSBuild\12.0\bin)来从命令行构建您的解决方案并获得更多细节,然后找到记录警告的.csproj.检查它的引用以及使用不同版本的相同公共程序集的其他项目的引用。
编辑:您也可以在VS2013中直接设置构建详细信息。转到工具>选项菜单,然后转到项目和解决方案并将MSBuild详细程度设置为诊断
编辑:由于我使用Resharper提示添加引用而不是使用“添加引用”对话框,所以我的情况警告是由于我添加引用而不带版本号,尽管可以选择v4和v12两个版本。
<Reference Include="Microsoft.Build, Version=12.0.0.0, ..." />
<Reference Include="Microsoft.Build.Framework" />

vs

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

在使用/v:diag详细度的MSBuild日志中,看起来像下面这样。它提供了两个引用冲突的详细信息:

  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]

11
我把那个命令的输出导向到一个日志文件,这样我就可以更方便地查看:msbuild "Foo.sln" /t:Rebuild /v:d > build.log - CrazyPyro
2
获取终端的最佳方法:https://dev59.com/TWEi5IYBdhLWcg3wN6Rt#22702405 - CrazyPyro
@CrazyPyro msbuild有一个“内置”的管道-- /l:FileLogger,Microsoft.Build.Engine;logfile=build.log -- 请注意此处记录器开关的解释 - drzaus
3
“构建日志”在哪里?我该如何找到它? - Prisoner ZERO
2
此答案展示了如何从msbuild获取更多细节,这是Mono用户关心的内容。所有其他答案都假定您正在使用VS并在Windows环境中运行。 - MickeyfAgain_BeforeExitOfSO

40

我只能用一个比较来支持Ruben的答案,比较这两个显示的消息:

enter image description here

和消息:

C:\Program Files (x86)\MSBuild\12.0\bin\Microsoft.Common.CurrentVersion.targets(1697,5): 警告 MSB3277: 找到无法解决的同一依赖程序集的不同版本之间的冲突。这些引用冲突在日志记录详细程度设置为 详细 时列在构建日志中。

所以,Ruben是正确的-这是不真实的。根本没有任何冲突,只是缺少程序集。当项目是ASP.NET应用程序时,这特别无聊,因为视图是按需编译的,也就是在第一次显示之前。这就是需要有可用程序集的时候。 (有一个选项可以将视图与其余代码一起预编译,但这是另一个故事。)另一方面,如果将详细程度设置为诊断,则会获得以下输出:

C:\Program Files (x86)\MSBuild\12.0\bin\Microsoft.Common.CurrentVersion.targets(1697,5): 警告 MSB3245: 无法解析此引用。无法找到程序集"System.Web.Razor,Version=3.0.0.0,Culture=neutral,PublicKeyToken=31bf3856ad364e35,processorArchitecture=MSIL"。请确认程序集在磁盘上存在。如果您的代码需要此引用,则可能会出现编译错误。

因此,您只需要执行以下操作:

  1. 手动添加对程序集的引用(在磁盘上找到它,也许是 GAC,并将其添加为“直接”引用),或
  2. 使用NuGet包(如果在库中发布)下载并引用其中包含的程序集。

更多关于NuGet库的信息点此。 更多关于预编译ASP.NET视图的信息点此


在VS 2017中,当我将“MSBuild项目生成输出详细程度”(而非日志文件)设置为详细(而非诊断)时,我会在输出窗口中收到“无法找到程序集”的错误消息。 - ALEXintlsos
@ALEXintlsos:显然这个功能已经改变了;但无论在哪里出现错误,按照指示去除它。 - Alexander Christov

23

在Visual Studio中更改构建详细程度有助于指明正确方向,按照以下步骤更改VS中的详细程度:

  1. 进入VS的“工具”->“选项”菜单
  2. 打开“项目和解决方案”->“生成和运行”
  3. 更改MSBuild项目生成输出详细程度的值。从 Quiet, Minimal, Normal, DetailedDiagnostic 中选择一个。

检查VS中的输出窗口(Ctrl+Alt+O)以查看构建日志中的更改。


18

重新强调@elshev的一个评论: 右键单击解决方案->管理解决方案的NuGet包->在“整合”下,您可以查看是否安装了不同版本的相同软件包。 在那里更新软件包。 冲突错误已解决。


2
这对我没有解决。我不得不卸载Newtonsoft.JSON并通过NuGet重新安装。这更新了其他包的依赖关系。 - Garr Godfrey
当使用像Resharper这样的工具自动添加DLL缺失引用时,我也遇到了类似的情况。在这里,“始终添加Nuget”可能是一个不错的建议。 - Shaswat Rungta
它对我不起作用,因为卸载软件包时会尝试构建该软件包,但由于软件包之间存在冲突,因此无法完成构建。因此,我甚至无法重新安装该软件包 :( - nickornotto

16

那我怎么才能消除这个警告?

你可能需要重新安装或升级NuGet包来解决这个问题。(参考链接)


2
这个问题对我来说已经解决了,方法是在Visual Studio拒绝正确重新安装一个包时,结合重启Visual Studio。 - Ohad Schneider
23
最简单的检查方法:右键点击解决方案-> 管理解决方案的 NuGet 程序包 -> 在合并下面,您可以看到是否安装了不同版本的相同程序包。 - elshev

12

我正在使用Visual Studio 2017,更新了一些Nuget包后遇到了这个问题。对我有用的方法是打开我的web.config文件,找到<runtime><assemblyBinding>节点并删除它。保存web.config并重新编译项目。

查看Error List窗口,你会看到一个长长的关于绑定冲突的警告。双击它,它将自动以正确的映射重新创建<runtime><assemblyBinding>块。


8
根据 dotnet CLI issue 6583 所述,问题可以通过使用 dotnet nuget locals --clear all 命令解决。

1
这对我没有起作用,运行命令后情况仍然相同。 - Zimano
@Zimano 这对我起作用了,但只有在退出 Visual Studio 并重新启动后才有效!然后重新构建项目解决了问题。 - Matthew M.

5

我可以通过在Web项目中使用Nuget包安装Newtonsoft Json来解决这个问题。


2

显然,这个问题有很多不同的原因和解决方案。为了加入我的观点,我们升级了一个之前在我们Web项目中直接引用的程序集(System.Net.Http)到NuGet管理的版本。这移除了该项目内的直接引用,但我们的测试项目仍包含直接引用。将两个项目都升级使用NuGet管理的程序集解决了此问题。


网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接