Visual Studio 2017(15.5.4)的构建日志让我对如何摆脱警告感到困惑
发现无法解析的“Microsoft.WindowsAzure.Storage”的不同版本之间存在冲突。当日志详细程度设置为详细时,这些引用冲突将在构建日志中列出。 Animals.Swine.Functions C:\ Program Files(x86)\ Microsoft Visual Studio \ 2017 \ Enterprise \ MSBuild \ 15.0 \ Bin \ Microsoft.Common.CurrentVersion.targets
There was a conflict between "Microsoft.WindowsAzure.Storage, Version=7.2.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" and "Microsoft.WindowsAzure.Storage, Version=8.1.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35".
"Microsoft.WindowsAzure.Storage, Version=7.2.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" was chosen because it was primary and "Microsoft.WindowsAzure.Storage, Version=8.1.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" was not.
References which depend on "Microsoft.WindowsAzure.Storage, Version=7.2.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" [D:\Repos\Animals\src\Animals.Swine\packages\WindowsAzure.Storage.7.2.1\lib\net40\Microsoft.WindowsAzure.Storage.dll].
D:\Repos\Animals\src\Animals.Swine\packages\WindowsAzure.Storage.7.2.1\lib\net40\Microsoft.WindowsAzure.Storage.dll
Project file item includes which caused reference "D:\Repos\Animals\src\Animals.Swine\packages\WindowsAzure.Storage.7.2.1\lib\net40\Microsoft.WindowsAzure.Storage.dll".
Microsoft.WindowsAzure.Storage, Version=7.2.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL
References which depend on "Microsoft.WindowsAzure.Storage, Version=8.1.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" [].
D:\Repos\Animals\src\Animals.Common\Animals.Common.Functions\bin\Debug\net461\bin\Animals.Common.Functions.dll
Project file item includes which caused reference "D:\Repos\Animals\src\Animals.Common\Animals.Common.Functions\bin\Debug\net461\bin\Animals.Common.Functions.dll".
D:\Repos\Animals\src\Animals.Common\Animals.Common.Functions\bin\Debug\net461\bin\Animals.Common.Functions.dll
D:\Repos\Animals\src\packages\Microsoft.Azure.WebJobs.2.1.0\lib\net45\Microsoft.Azure.WebJobs.Host.dll
Project file item includes which caused reference "D:\Repos\Animals\src\packages\Microsoft.Azure.WebJobs.2.1.0\lib\net45\Microsoft.Azure.WebJobs.Host.dll".
Microsoft.Azure.WebJobs.Host, Version=2.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL
Microsoft.Azure.WebJobs.Extensions, Version=2.0.0.0, Culture=neutral, processorArchitecture=MSIL
D:\Repos\Animals\src\Animals.Common\Animals.Common\bin\Debug\net45\Animals.Common.dll
Project file item includes which caused reference "D:\Repos\Animals\src\Animals.Common\Animals.Common\bin\Debug\net45\Animals.Common.dll".
D:\Repos\Animals\src\Animals.Swine\Animals.Swine\bin\Debug\Animals.Swine.dll
D:\Repos\Animals\src\Animals.Common\Animals.Common\bin\Debug\net45\Animals.Common.dll
D:\Repos\Animals\src\Animals.Swine\packages\Microsoft.Azure.WebJobs.Extensions.2.0.0\lib\net45\Microsoft.Azure.WebJobs.Extensions.dll
Project file item includes which caused reference "D:\Repos\Animals\src\Animals.Swine\packages\Microsoft.Azure.WebJobs.Extensions.2.0.0\lib\net45\Microsoft.Azure.WebJobs.Extensions.dll".
Microsoft.Azure.WebJobs.Extensions, Version=2.0.0.0, Culture=neutral, processorArchitecture=MSIL
如果我们浏览据报道使用Storage 8.1.1.0的引用,我们会看到第一个,第三个和最后一个引用它们。为什么会这么想?这甚至意味着什么?
D:\Repos\Animals\src\Animals.Common\Animals.Common.Functions\bin\Debug\net461\bin\Animals.Common.Functions.dll
Project file item includes which caused reference "D:\Repos\Animals\src\Animals.Common\Animals.Common.Functions\bin\Debug\net461\bin\Animals.Common.Functions.dll".
D:\Repos\Animals\src\Animals.Common\Animals.Common.Functions\bin\Debug\net461\bin\Animals.Common.Functions.dll
...
D:\Repos\Animals\src\Animals.Common\Animals.Common\bin\Debug\net45\Animals.Common.dll
Project file item includes which caused reference "D:\Repos\Animals\src\Animals.Common\Animals.Common\bin\Debug\net45\Animals.Common.dll".
D:\Repos\Animals\src\Animals.Swine\Animals.Swine\bin\Debug\Animals.Swine.dll
D:\Repos\Animals\src\Animals.Common\Animals.Common\bin\Debug\net45\Animals.Common.dll
D:\Repos\Animals\src\Animals.Swine\packages\Microsoft.Azure.WebJobs.Extensions.2.0.0\lib\net45\Microsoft.Azure.WebJobs.Extensions.dll
Project file item includes which caused reference "D:\Repos\Animals\src\Animals.Swine\packages\Microsoft.Azure.WebJobs.Extensions.2.0.0\lib\net45\Microsoft.Azure.WebJobs.Extensions.dll".
Microsoft.Azure.WebJobs.Extensions, Version=2.0.0.0, Culture=neutral, processorArchitecture=MSIL
第二个似乎是一个更好的检查和讨论的地方:
D:\Repos\Animals\src\packages\Microsoft.Azure.WebJobs.2.1.0\lib\net45\Microsoft.Azure.WebJobs.Host.dll
Project file item includes which caused reference "D:\Repos\Animals\src\packages\Microsoft.Azure.WebJobs.2.1.0\lib\net45\Microsoft.Azure.WebJobs.Host.dll".
Microsoft.Azure.WebJobs.Host, Version=2.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL
Microsoft.Azure.WebJobs.Extensions, Version=2.0.0.0, Culture=neutral, processorArchitecture=MSIL
因此,如果我正确阅读,Microsoft.Azure.WebJobs.Host, Version=2.1.0.0
和Microsoft.Azure.WebJobs.Extensions, Version=2.0.0.0
都应该引用Microsoft.WindowsAzure.Storage, Version=8.1.1.0
。但是,如果我们查看Nuget依赖项,WebJobs引用7.2.1.0
和WebJobs.Extensions只会引用回[WebJobs]。
我没有看到任何引用8.1.1.0
的内容!任何项目都不直接引用存储,我看不到间接引用。
我在“D:\ Repos \ Animals \ src \ Animals.Swine \ Animals.Swine.Functions \ bin \”上运行AsmSpy,但它甚至没有显示存储冲突。
如何确定Storage 8.1.1.0引用的来源?
更新:我进行了文本搜索,发现绑定重定向设置为“8.1.1.0”作为newVersion。我将其更改为“7.2.1.0”并且警告消失了。即使警告已经消失,我仍然会打开这个问题,以便有人能够深入了解如何阅读构建日志以及日志如何指向我们正确的方向。
答案 0 :(得分:2)
如何确定Storage 8.1.1.0引用的来源?
构建日志可以帮助我们解决大多数问题,但它不能解决所有问题。它仍然需要我们手动解决这些问题。因为Visual Studio / MSBuild无法直接找到问题的根本原因。
当我们遇到此MSB3247 / MSB3277错误时,解决此问题的最佳方法是将MSBuild输出日志转为诊断(工具 - >选项 - >项目和解决方案 - &gt ;构建并运行,设置MSBuild项目构建输出详细程度),然后找到依赖Microsoft.WindowsAzure.Storage
的引用,检查是否有不同版本的Microsoft.WindowsAzure.Storage
被引用。
在构建日志中,我们发现项目文件项包含导致引用Microsoft.Azure.WebJobs.2.1.0
和Microsoft.Azure.WebJobs.Extensions.2.0.0
然后检查这两个包的依赖关系,它们都没有引用Microsoft.WindowsAzure.Storage, Version=8.1.1.0
。
为了确认,您可以使用Vladimir在评论中提供的方法。
此时此冲突不应来自参考。然后我们应该检查与参考版本相关的文件,例如app.confi
g或web.config
,找到关于引用Microsoft.WindowsAzure.Storage
的绑定重定向,检查绑定重定向是否正确。
因此,有时我们不能仅根据构建日志信息直接解决问题,手动故障排除也是必不可少的。