. 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后修复的)。
有没有更好的(更自动化的)方法?
当前回答
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社区→首选项…→项目→构建日志→冗长
其他回答
Mike Hadlow发布了一个名为AsmSpy的小控制台应用程序,它很好地列出了每个程序集的引用:
Reference: System.Net.Http.Formatting
4.0.0.0 by Shared.MessageStack
4.0.0.0 by System.Web.Http
Reference: System.Net.Http
2.0.0.0 by Shared.MessageStack
2.0.0.0 by System.Net.Http.Formatting
4.0.0.0 by System.Net.Http.WebRequest
2.0.0.0 by System.Web.Http.Common
2.0.0.0 by System.Web.Http
2.0.0.0 by System.Web.Http.WebHost
与依赖MSBuild输出相比,这是获取警告MSB3247底部的更快方法。
最简单的方法是不考虑(内部)依赖关系:
打开“解决方案资源管理器”。 点击“显示所有文件” 扩大“引用” 您将看到一个(或多个)引用与其他引用的图标略有不同。通常情况下,它会有一个黄色的方框,建议你记下它。把它拿掉。 重新添加引用并编译代码。 这是所有。
在我的例子中,MySQL引用有一个问题。以某种方式,我可以在所有可用引用的列表下列出它的三个版本。我遵循了上面的方法1到6,它对我很有效。
我发现(至少在Visual Studio 2010中),您需要将输出详细信息设置为至少详细的,以便能够发现问题。
这可能是我的问题是一个参考,以前是一个GAC参考,但这不再是我的机器重新安装后的情况。
此警告产生于默认ASP。NET MVC 4测试版 在这里看到的
中,此警告的任何强制转换都可以通过手动编辑 .csproj文件。 修改……: Reference Include="System.Net.Http" 阅读......: Reference Include="System.Net. "Http, Version = 4.0.0.0 "
ASP。NET构建管理器通过按字母顺序浏览文件夹来构建网站,对于每个文件夹,它会找出它的依赖项并首先构建依赖项,然后再构建选定的文件夹。
在这种情况下,有问题的文件夹是~/Controls,在开始时被选择构建,出于未知的原因,它将一些控件构建为一个单独的程序集,而不是像其他控件一样在同一个程序集中(似乎与某些控件依赖于同一文件夹中的其他控件的事实有关)。
然后构建的下一个文件夹(~/File-Center/Control)依赖于根文件夹~/,根文件夹~/依赖于~/Controls,所以文件夹~/Controls再次被构建,只是这次分离到自己程序集的控件现在与其他控件连接到相同的程序集,分离的程序集仍然被引用。
因此此时至少有2个程序集具有相同的控件,构建失败。
虽然我们仍然不知道为什么会发生这种情况,我们能够通过将Controls文件夹名称更改为ZControls来解决它,这样它就不会在~/File-Center/Control之前构建,只在之后构建,这样它就应该被构建。