项目参考 DLL 版本地狱
我们在让 Visual Studio 从我们的项目之一获取最新版本的 DLL 时遇到问题。
我们有多个类库项目（例如 BusinessLogic、ReportData）和许多 Web 服务，每个服务都有对我们编写的连接 DLL 的引用（对连接 DLL 的引用就是问题所在）。
我们总是将引用指向 bin/debug 文件夹中的 DLL（这是我们始终为任何给定项目构建的位置），并且所有自定义 DLL 引用都具有 CopyLocal = True 和 SpecificVersion = False
ReportData 具有对业务逻辑的引用（这也是有对连接的引用 - 我不明白为什么这会导致问题，但认为值得一提）
奇怪的是，当您单击“添加引用”并浏览到 Connectivity/bin/debug 时 - 您将鼠标悬停在 DLL 文件上，会显示正确的（最新）版本（版本和文件版本始终一起递增），但是当您单击“确定”时，会提取以前的版本号。即使当我查看当前项目调试文件夹（其中复制本地将在编译后放置 DLL）时，它也会显示最新版本号。 - 我在 Visual Studio 之外无法在任何地方找到该 DLL 的先前版本，但在该项目引用中它具有旧版本 - 即使路径是正确的。
我不知道它可能从哪里获得旧版本。或者甚至是为什么它想要那个。
这可能是我遇到过的最令人沮丧的问题。
有谁知道如何确保最新版本通过（最好是自动或编译时）。
编辑：
虽然不完全是我正在处理的场景，但我正在阅读 这篇文章及其某处提到了 CLR 忽略修订号。可以理解（尽管这以前不是问题 - 我们正在修订 39），所以我想我会更新内部版本号，但仍然不起作用。在徒劳的尝试中，我虽然会更新次要版本号，看看是否有任何区别。
我并不是说这就是答案，因为我必须先检查很多事情，但从表面上看，这似乎已经解决了我的问题......
进一步编辑： 在其他类库中，这似乎已经解决了问题，但是在测试 Windows 应用程序中，它仍然会拉出以前的版本:(
如果我再次增加次要版本号，同样的问题又回来了，我留下了错误的版本 有人
进一步编辑 - 我创建了一个全新的项目，添加了一个引用，但仍然遇到了完全相同的问题，这表明问题仅限于我引用的项目。希望我知道为什么
遇到过这个问题并知道如何解决 。绕过它
？
We're having problems getting visual studio to pick up the latest version of a DLL from one of our projects.
We have multiple class library projects (e.g. BusinessLogic, ReportData) and a number of web services, each has a reference to a Connectivity DLL we've written (this ref to the connectivity DLL is the problem).
We always point references to the DLL in the bin/debug folder, (which is where we always build to for any given project) and all custom DLL references have CopyLocal = True and SpecificVersion = False
ReportData has a reference to business logic (which also has a reference to connectivity - I don't see why this should cause a problem, but thought it is worth mentioning)
The weird thing is, when you click "Add Reference" and browse to Connectivity/bin/debug - you hover the mouse over the DLL file, the correct (latest) version is shown (version and file version are always incremented together), but when you click ok, a previous version number is pulled though. Even when I look in the current projects debug folder (where copy local would put the DLL after compiling) that shows the latest version number. - NO WHERE does can I find the previous version of the DLL outside of visual studio, but in that project references it has the old version - even though the path is correct.
I'm at a loss as to where it might be getting the old versions from. Or even why it wants that one.
This is possibly the most frustraighting problem I have ever come across.
Does anyone know how to ensure the latest version is pulled through (preferably automatically or on compile).
EDIT:
Although not exactly the scenario I'm dealing with I was reading this article and somewhere it mentions about CLR ignoring revision numbers. Understandable (even though this hasn't been a problem before - we're on revision 39), so I thought I would update the build number, still didn't work. In a vain attempt I though I would update the minor version number and see if that made any difference.
I'm not saying this is the answer as I have to check quite a few things first, but on the face of it, this seems to have solved my problem...
Further edit:
In other class libraries this seems to have solved the problem, however in a test windows application it still pulls a previous version through :(
If I increment the minor version number again, the same problem come back and I am left with the wrong version being pulled though.
Further Edit - I created an entirly new project, added a reference and still had the exact same problem. This suggests the problem is restriced to the project I am referencing. Wish I knew why!
Anyone had this problem before and know how to get around it?
HELP!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（10）
为了避免 dll 地狱，我建议您在项目中创建一个
lib文件夹，并将所有共享程序集放入此文件夹中。接下来，仅添加此文件夹中的引用。这样您的项目是独立的，并且您确切地知道它从哪里挑选参考文献。如果您想使用较新版本更新某些程序集，请将其复制到lib文件夹并重建您的项目。另请确保不要将引用的程序集放入 GAC 中，因为它们可能会首先被选取。
To avoid the dll hell I would recommend you to create a
libfolder inside your project and put all shared assemblies in this folder. Next you Add References only from this folder. This way your project is self contained and you know exactly where it is picking the references from. If you want to update some assembly with a newer version you copy it to thelibfolder and rebuild your project.Also make sure you don't the referenced assemblies into the GAC as they might be picked up first.
您可以尝试的选项很少。
There are few options that you can try.
为了克服这个问题，我删除了所有引用，然后再次将它们全部添加回来。我不知道为什么这是解决方案。
有可能在一个项目中，某个 DLL 不正确，而 Visual Studio 提取并使用的正是这个不正确的 DLL。
编辑：
其他时候，发生此错误的原因是当前项目中引用的 DDL (A) 也被另一个 DLL (B) 引用。不重建另一个 DLL (B) 似乎会阻止 VS 在当前项目中引用正确版本的 DLL (A)，因此它会引入旧版本的 DLL (A)。
To overcome this, I removed EVERY reference, then added them all back in again. I don't know why this is the solution.
It is possible that in one project a DLL was incorrect, and it is this incorrect DLL that was pulled through by visual studio and used.
Edit:
Other times this error has occurred is due to a DDL (A) being referenced in the current project also being referenced by another DLL (B). Not rebuilding this other DLL (B) seems to prevent VS from referencing the correct version of DLL (A) in the current project and thus it brings through an older version of DLL (A).
您是否尝试过将参考添加为项目参考？即添加引用... ->项目选项卡 ->选择您的项目
Have you tried adding the reference as a Project Reference? i.e. Add Reference... -> Projects tab -> Select your project
我们（并且，作为我们团队中唯一的 .NET 开发人员，我的意思是我）也遇到了完全相同的问题。我追踪到了一个被引用的 dll，而该 dll 又再次引用了患有版本炎的 dll。似乎因为我没有更新所有引用该 dll 的引用，所以它在构建过程中的某个时刻被旧版本替换。
我遇到的症状之一是，当我在代码编辑器中时，我添加到引用项目中的新类将具有适当的颜色，但是当我点击“构建”时，它会变回黑色，并且我收到一条消息说该类确实不存在（以及一个非常讽刺的“您缺少程序集引用吗？”）。这让我相信问题一定发生在构建阶段。
因此，我建议构建指向此 DLL 的所有其他项目，并重新添加它们的引用。
We (and, as the only .NET developer on our team, by that I mean I) had the exact same problem. I traced it down to a referenced dll, which in turn AGAIN references the dll suffering from versionitis. It seems that because I wasn't updating all the references which in turn reference the dll, it was replaced by an older version at some point during the build process.
One of the symptoms I experienced was that when I am in the code editor, the new class I added to the referenced project would be coloured appropriately, but when I hit Build, it changes back to black and I get a message saying the class does not exist (along with a very sarcastic "Ar you missing an assembly reference?"). This led me to believe that the problem has to happen during the Build phase.
I would therefore suggest building any and every other project that points to this DLL and re-add their references too.
启用FusionLog，DLL加载失败后，打开文件夹C:\FusionLog\Default\devenv.exe中DLL名称的文件。这将显示 DLL 真正加载的路径。
就我而言，旧版本神秘地出现在
C:\Program Files\Microsoft Visual Studio 10\Common7\IDE 中！
为了阻止这种情况再次发生，我向 Common7\IDE 上的每个人添加了一条安全规则“拒绝写入”。
Enable FusionLog and after the DLL fails to load, open the file with the DLL's name in the folder C:\FusionLog\Default\devenv.exe. This will show the path from where the DLL was really loaded.
In my case, an old version had mysteriously appeared in
C:\Program Files\Microsoft Visual Studio 10\Common7\IDE !
To stop this ever happening again, I added a security rule "Deny Write" to Everyone on Common7\IDE.
我遇到了与此处描述的问题类似的问题，只不过我对问题的解决方案与我编译代码的方式有关。构建、清理和重建之间是有区别的。就我而言，我只是在更改之间使用“构建”，并且依赖解决方案中的 dll 并未与设置引用的其他解决方案的所有更改一起继承。我通过使用 Rebuild 解决了这个问题，它会清理、编译和链接所有源文件，无论它们是否更改。然后第一个解决方案中的 dll 被更新并自动复制到第二个解决方案，在第二个解决方案中设置了引用并解决了问题。
干杯，我希望这有帮助。
I had a problem similar to what is described here except that my solution to the problem had to do with how I was compiling the code. There is a difference between build, clean and Rebuild. In my case, I was just using a Build between my changes and the dll from the dependent solution were not being carried over with all the changes to the other solution where the reference was set. I solved it by using Rebuild which cleans, compiles and links all source files regardless of whether they changed or not. Then the dll from the the first solution was updated and copied over automatically to the 2nd solution where the reference was set and the problem was solved.
Cheers, I hope this helps.
类似的症状 - 问题出在项目属性、参考中的“参考路径”中。
完整的描述和解决方案在这里：
引用的程序集自动被 Visual Studio 替换
视觉工作室/22810867#22810867
Similar symptoms - problem was in "Referene paths" in Project Properties, Reference.
Full descrtiption and solution here:
Referenced assemblies automatically replaced by visual studio
visual-studio/22810867#22810867
检查一下：
在本例中，假设您已将 abc.dll 从版本 1 更新到版本 2，并在 Web 应用程序中重新引用。但在构建过程中，abc.dll 的版本 2 将更改回版本 1，因为 xyz.dll 使用版本 1，并且 Web 应用程序在 xyz.dll 自动更新期间将 abc.dll 版本 2 覆盖回 abc.dll 版本 1 。
解决方案：将 abc.dll 版本 2 的更新版本也放在 xyz.dll 的类项目 bin 中
希望，上述详细信息会有所帮助，祝你好运
Check Out this things:
In this case, suppose, you've updated abc.dll from version 1 to version 2 and re-referenced in your web application. but during building process, the version 2 of abc.dll will change back to version 1, because, xyz.dll uses version 1 and web application overwrite abc.dll version 2 back to abc.dll version 1 during auto update on xyz.dll.
Solution: place updated version of abc.dll version 2 in class project bin of xyz.dll , too
Hope, above details will help, good luck
可能的原因之一是参考路径。如果有任何对旧 dll 文件夹的引用，VS 会将其用作主要引用，即使您添加了新的 dll 引用。
One possible reason is the Reference PATHs. If there's any reference to the old dll folder, VS will use it as the main reference, even though you added the new dll reference.