同一nuget软件包中同一dll的不同版本。
我有一个基本的nuget库，称为Foundation.dll。 我还有另外5个使用不同版本的Foundation.dll的Nuget库。 一切都在一个项目中。
我的问题是，当我构建一个项目时，vs .NET显然只会将一个基础放在bin/debug文件夹中。因此，VS/.NET如何决定Nuget Package的Foundation.dll应放入BIN/DEBUG文件夹中。是随机的吗？
如果我直接在项目中确实参考Foundation.dll，则将我的直接参考版本放入bin/debug文件夹中，但对于团队中的其他一些开发人员，它将放置一个较旧的版本。
非常恐怖的是，两台不同机器中的相同精确分支代码的工作方式不同。我在Foundation.dll的方法之一中添加了一个论点＆amp;对于一个开发人员而言，它正在工作，但对于另一个开发人员而言，相同的确切代码给出了汇编错误。
最终解决此问题的方法是什么？我应该在项目中做出什么改变？
谢谢。
I have one base nuget library called Foundation.dll.
I have another 5 nuget libraries which are using a different version of Foundation.dll.
Everything is in one project.
My question is when I build a project, VS .Net is obviously going to put only one Foundation.dll in the bin/debug folder. So how VS/.Net decides which nuget package's foundation.dll should be put in the bin/debug folder. Is it randomly?
If I do reference Foundation.dll directly in the project then it is putting my direct reference version into the bin/debug folder but for some other developers in the team, it is putting an older version.
it is very scary that the same exact branch code in 2 different machines works differently. I added one argument in one of Foundation.dll's methods & for one developer it is working but for another developer, the same exact code gives a compilation error.
What is the ultimate solution to this problem? What change should I make in my project?
Thank you.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
这是一个困难的话题，是的，有很多因素确定要将哪个版本放在bin文件夹上。通常，编译器会自动从所有依赖项中选择最新版本。但是，尤其是如果您的解决方案中有几个“最终”组件（例如EXE，单位测试库），则编译器有时会弄错。通常，该代码无论如何都可以工作，但是我同意，这很可怕。
实际结果可能取决于构建顺序，构建环境（无论是从命令行还是在VS内部构建等）。我和我的团队很难弄清楚这个问题的最佳方法。
我们发现的最安全的方法是直接在项目中参考您的软件包的最新版本。这不是最新版本，而是解决方案中任何地方使用的最新版本。当然，这仅在版本向后兼容时才起作用。如果某些库需要 依赖性的较旧版本，而您无法重建该库，那么您会遇到真正的麻烦。
This is a difficult topic and yes, there are a lot of factors that determine which version is being put to the bin folder. Normally, the compiler chooses the latest version from all the dependencies automatically. But particularly if you have several "final" assemblies in your solution (e.g exe's, unit test libraries) the compiler sometimes gets it wrong. Usually, the code works anyway, but I agree, this is scary.
The actual outcome may depend on the build order, build environment (whether building from the command line or within VS, etc.). Me and my team has had a hard time figuring out the best way around this problem.
The safest approach we found is to reference the latest version of your package directly in the project. This does not need to be the latest version available, but the latest version used anywhere within your solution. Of course, this only works if the versions are backwards compatible. If some library requires an older version of the dependency and you can't rebuild that library, you are in for really big trouble.
我遇到了同样的问题。解决方案中的一个项目取决于库的.NET标准版本，而另一些项目则期待经典的框架版本。
正如PMF写的那样，输出中最终将出现哪个库取决于构建顺序。
我已经通过将.NET标准版本复制到后构建事件中的输出文件夹中解决了它。
I've met the same issue. One project in the solution was depending on .net standard version of a library, while others were expecting a classic framework version.
As PMF wrote, which library will finally occur in the output depends on a build order.
I've solved it by copying the .net standard version into the output folder on post-build events.
输出不应取决于随机的事物，这些情况有一些（复杂的）规则：
https://learn.microsoft.com/en-comrosoft.com/en-en-us/nuget/概念/依赖性解决
它应该选择直接依赖性而不是间接依赖性。
在“重建全部重建”时，您仍然会获得不同的结果吗？
The output should not depend on random things, there's some (complex) rules for these situations:
https://learn.microsoft.com/en-us/nuget/concepts/dependency-resolution
It should choose the direct dependency over the indirect ones.
Do you still get different results when doing "rebuild all"?