. net 3.5解决方案在使用msbuild编译时出现此警告。
有时NDepend可能会有所帮助,但在这种情况下,它没有提供任何进一步的细节。像Bob一样,我最终不得不在ILDASM中打开每个程序集,直到找到引用依赖程序集的旧版本。
我确实尝试使用VS 2010 Beta 2的MSBUILD(连接文章指出这在CLR的下一个版本中得到了修复),但也没有提供更多的细节(可能是在Beta 2后修复的)。
有没有更好的(更自动化的)方法?
. net 3.5解决方案在使用msbuild编译时出现此警告。
有时NDepend可能会有所帮助,但在这种情况下,它没有提供任何进一步的细节。像Bob一样,我最终不得不在ILDASM中打开每个程序集,直到找到引用依赖程序集的旧版本。
我确实尝试使用VS 2010 Beta 2的MSBUILD(连接文章指出这在CLR的下一个版本中得到了修复),但也没有提供更多的细节(可能是在Beta 2后修复的)。
有没有更好的(更自动化的)方法?
当前回答
我做了一个基于Mike Hadlow的应用程序:AsmSpy。
我的应用程序是一个带有GUI的WPF应用程序,可以从我的家庭web服务器下载:AsmSpyPlus.exe。
代码可在:GitHub
其他回答
此警告产生于默认ASP。NET MVC 4测试版 在这里看到的
中,此警告的任何强制转换都可以通过手动编辑 .csproj文件。 修改……: Reference Include="System.Net.Http" 阅读......: Reference Include="System.Net. "Http, Version = 4.0.0.0 "
Visual Studio for Mac Community新增:
由于AMissico的回答需要更改日志级别,而ASMSpy和ASMSpyPlus都不能作为跨平台解决方案,下面是Visual Studio for Mac的一个简短补充:
https://learn.microsoft.com/en-us/visualstudio/mac/compiling-and-building
它在Visual Studio社区→首选项…→项目→构建日志→冗长
如果您有resharper,删除解决方案中所有未使用的参考。
ASP。NET构建管理器通过按字母顺序浏览文件夹来构建网站,对于每个文件夹,它会找出它的依赖项并首先构建依赖项,然后再构建选定的文件夹。
在这种情况下,有问题的文件夹是~/Controls,在开始时被选择构建,出于未知的原因,它将一些控件构建为一个单独的程序集,而不是像其他控件一样在同一个程序集中(似乎与某些控件依赖于同一文件夹中的其他控件的事实有关)。
然后构建的下一个文件夹(~/File-Center/Control)依赖于根文件夹~/,根文件夹~/依赖于~/Controls,所以文件夹~/Controls再次被构建,只是这次分离到自己程序集的控件现在与其他控件连接到相同的程序集,分离的程序集仍然被引用。
因此此时至少有2个程序集具有相同的控件,构建失败。
虽然我们仍然不知道为什么会发生这种情况,我们能够通过将Controls文件夹名称更改为ZControls来解决它,这样它就不会在~/File-Center/Control之前构建,只在之后构建,这样它就应该被构建。
有时候@AMissico的答案是不够的。在我的例子中,我在Output窗口中找不到错误,所以我决定创建一个日志文件并分析它,执行以下步骤:
将构建日志保存到一个文件…https://msdn.microsoft.com/en-us/library/ms171470.aspx msbuild MyProject的。proj /fl /flp:logfile=MyProjectOutput.log 查找文本:警告MS…或者具体的警告信息:(例如,第9293行)发现不同版本之间存在冲突…和冲突错误的完整细节将在此消息的上面(例如,第9277行)。
Visual Studio 2013