. net 3.5解决方案在使用msbuild编译时出现此警告。
有时NDepend可能会有所帮助，但在这种情况下，它没有提供任何进一步的细节。像Bob一样，我最终不得不在ILDASM中打开每个程序集，直到找到引用依赖程序集的旧版本。
我确实尝试使用VS 2010 Beta 2的MSBUILD(连接文章指出这在CLR的下一个版本中得到了修复)，但也没有提供更多的细节(可能是在Beta 2后修复的)。
有没有更好的(更自动化的)方法?
当前回答
最简单的方法是不考虑(内部)依赖关系:
打开“解决方案资源管理器”。 点击“显示所有文件” 扩大“引用” 您将看到一个(或多个)引用与其他引用的图标略有不同。通常情况下，它会有一个黄色的方框，建议你记下它。把它拿掉。 重新添加引用并编译代码。 这是所有。
在我的例子中，MySQL引用有一个问题。以某种方式，我可以在所有可用引用的列表下列出它的三个版本。我遵循了上面的方法1到6，它对我很有效。
其他回答
我也有这个问题，并使用了AMissico的建议，发现了这个问题(尽管必须将冗长级别设置为详细。
在找到罪魁祸首后，问题其实很简单。
背景: 我把我的项目从VS2008升级到VS2010。在VS2008中，目标框架是3.5，当我把它带入VS2010时，我把它切换到4 (Full)。我还升级了一些第三方组件，包括水晶报表。
结果发现大多数系统引用指向4.0.0.0版本，但有几个没有自动更改(System和System. web . services)，仍然指向2.0.0.0版本。水晶报告引用4.0.0.0，所以这是冲突发生的地方。只需将光标放在解决方案资源管理器中的第一个System库上，向下移动列表并查找对2.0.0.0的任何引用，删除并重新添加新的4.0.0.0版本就可以了。
奇怪的是，大多数参考文献都被正确更新了，如果不是水晶报告，我可能永远都不会注意到……
正如这里提到的，您需要删除未使用的引用，警告就会消失。
ASP。NET构建管理器通过按字母顺序浏览文件夹来构建网站，对于每个文件夹，它会找出它的依赖项并首先构建依赖项，然后再构建选定的文件夹。
在这种情况下，有问题的文件夹是~/Controls，在开始时被选择构建，出于未知的原因，它将一些控件构建为一个单独的程序集，而不是像其他控件一样在同一个程序集中(似乎与某些控件依赖于同一文件夹中的其他控件的事实有关)。
然后构建的下一个文件夹(~/File-Center/Control)依赖于根文件夹~/，根文件夹~/依赖于~/Controls，所以文件夹~/Controls再次被构建，只是这次分离到自己程序集的控件现在与其他控件连接到相同的程序集，分离的程序集仍然被引用。
因此此时至少有2个程序集具有相同的控件，构建失败。
虽然我们仍然不知道为什么会发生这种情况，我们能够通过将Controls文件夹名称更改为ZControls来解决它，这样它就不会在~/File-Center/Control之前构建，只在之后构建，这样它就应该被构建。
最简单的方法是不考虑(内部)依赖关系:
打开“解决方案资源管理器”。 点击“显示所有文件” 扩大“引用” 您将看到一个(或多个)引用与其他引用的图标略有不同。通常情况下，它会有一个黄色的方框，建议你记下它。把它拿掉。 重新添加引用并编译代码。 这是所有。
在我的例子中，MySQL引用有一个问题。以某种方式，我可以在所有可用引用的列表下列出它的三个版本。我遵循了上面的方法1到6，它对我很有效。
有时候@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
