我目前正在开发一个。net应用程序,它由20个项目组成。其中一些项目是使用。net 3.5编译的,其他一些仍然是。net 2.0项目(到目前为止没有问题)。

问题是,如果我包含一个外部组件,我总是得到以下警告:

发现同一依赖程序集的不同版本之间存在冲突。

这个警告到底是什么意思,有没有可能排除这个警告(比如在源代码文件中使用#pragma disable)?


当前回答

在Mac Visual Studio上编辑.resx文件时似乎有一个问题。 我真的不知道发生了什么,但当我在Mac上编辑一些.resx文件时,我就遇到了这个问题。 我在Windows上打开项目,打开文件,它们就像没有被编辑过一样。 于是我编辑了它们,保存了下来,Mac上的一切也都恢复正常了。

其他回答

这实际上取决于外部组件。当你在. net应用程序中引用一个外部组件时,它会生成一个GUID来标识该组件。当某个项目引用的外部组件与另一个程序集中的另一个此类组件名称相同但版本不同时,会发生此错误。

当您使用“浏览”查找引用并添加错误版本的程序集时,有时会发生这种情况,或者您的代码存储库中组件的版本与您在本地机器中安装的版本不同。

尝试找出哪些项目有这些冲突,从引用列表中删除组件,然后再次添加它们,确保指向相同的文件。

基本上,当您引用的程序集将“Copy Local”设置为“True”时,就会发生这种情况,这意味着DLL的副本与exe一起放置在bin文件夹中。

由于Visual Studio也会复制所引用程序集的所有依赖项,因此最终可能会引用同一个程序集的两个不同构建。如果您的项目在不同的解决方案中,因此可以单独编译,则更有可能发生这种情况。

我解决这个问题的方法是在组装项目中将Copy Local设置为False。只针对可执行文件/web应用程序,在这些应用程序中,您需要运行成品的程序集。

希望这有意义!

当我的项目引用NETStandardLibrary时,我遇到了这样的问题,其中一个引用的程序集发布了netcore。只要把它作为网络标准发布,问题就解决了

下面是解决方案,.NET Core 3.0风格: https://github.com/HTD/ref-check

当你发现哪些冲突时,也许你就能解决这些冲突。 如果冲突的引用来自其他包,那么您要么不走运,要么需要使用源。

在我的例子中,冲突的包通常是我自己的,所以我可以修复依赖关系问题并重新发布它们。

另一件需要考虑和检查的事情是,确保没有任何正在运行的服务正在使用该bin文件夹。如果是,则停止服务并重新构建解决方案