项目参考DLL版本地狱

Question

我们在让visual studio从我们的某个项目中获取最新版本的DLL时遇到了问题。

我们有多个类库项目（例如BusinessLogic，ReportData）和许多Web服务，每个项目都引用了我们编写的连接DLL（这是对连接DLL的引用问题）。

我们总是在bin / debug文件夹中指向DLL的引用（这是我们总是为任何给定项目构建的），并且所有自定义DLL引用都有CopyLocal = True和SpecificVersion = False

ReportData有一个对业务逻辑的引用（它也引用了连接 - 我不明白为什么这会导致问题，但是认为值得一提）

奇怪的是，当您单击“添加引用”并浏览到连接/ bin / debug时 - 将鼠标悬停在DLL文件上，将显示正确的（最新）版本（版本和文件版本始终一起递增），但是当您单击“确定”时，会拉出先前的版本号。即使我查看当前项目调试文件夹（其中copy local将在编译后放置DLL）显示最新版本号。 - NO我在哪里可以找到Visual Studio之外的以前版本的DLL，但在该项目中引用它有旧版本 - 即使路径是正确的。

我不知道从哪个版本获得旧版本。甚至为什么它想要那个。

这可能是我遇到的最令人沮丧的问题。

有没有人知道如何确保最新版本被拉过（最好是自动或编译）。

编辑：

虽然不完全是我正在处理的场景，但我正在阅读this文章，并在某处提到CLR忽略修订号。可以理解（尽管之前这不是问题 - 我们正在修订版本39），所以我想我会更新内部版本号，仍然无法正常工作。我徒劳地试图更新次要版本号，看看是否有任何不同。

我不是说这是答案，因为我必须首先检查一些事情，但从表面上看，这似乎解决了我的问题......

进一步编辑： 在其他类库中，这似乎解决了这个问题，但是在测试Windows应用程序中，它仍然通过以下版本提取：（

如果我再次增加次要版本号，同样的问题又回来了，我留下了错误的版本。

进一步编辑 - 我创建了一个非常新的项目，添加了一个参考，但仍然有完全相同的问题。这表明问题仅限于我引用的项目。希望我知道为什么！

之前有人遇到过这个问题并知道如何解决这个问题吗？

HELP！

Answer 1

为了避免 dll hell ，我建议您在项目中创建一个lib文件夹，并将所有共享程序集放在此文件夹中。接下来，仅从此文件夹添加引用。通过这种方式，您的项目是自包含的，并且您确切地知道从中挑选引用的位置。如果要使用较新版本更新某个程序集，请将其复制到lib文件夹并重建项目。

另外，请确保您没有将引用的程序集放入GAC中，因为它们可能首先被选中。

Answer 2

您可以尝试的选项很少。

1. 编译项​​目并在输出窗口中查看以确认准确引用它的装配路径。
2. 在重新编译之前删除Obj文件夹。
3. 关闭并重新打开Visual Studio，因为VS有一些奇怪的行为可以让缓存保持Dll引用。
4. 如果您仍然看到问题，请使用此工具检查参考组件的确切位置。 Process Explorer。

Answer 3

为了解决这个问题，我删除了每个引用，然后将它们全部重新添加。我不知道为什么这是解决方案。

在一个项目中，DLL可能是不正确的，而且这个不正确的DLL是由visual studio提取并使用的。

编辑： 其他时候发生此错误是由于当前项目中引用的DDL（A）也被另一个DLL（B）引用。不重建这个其他DLL（B）似乎阻止VS在当前项目中引用正确版本的DLL（A），因此它带来了旧版本的DLL（A）。

Answer 4

您是否尝试将参考添加为项目参考？即添加参考... - ＆gt;项目标签 - ＆gt;选择你的项目

Answer 5

我们（并且，作为我们团队中唯一的.NET开发人员，我的意思是我）具有完全相同的问题。我将其追溯到一个引用的dll，反过来AGAIN引用了遭受版本炎的dll。似乎因为我没有更新反过来引用dll的所有引用，它在构建过程中的某个时刻被旧版本替换。

我遇到的一个症状是，当我在代码编辑器中时，我添加到引用项目中的新类将被适当地着色，但是当我点击Build时，它会变回黑色并且我收到一条消息说这个类不存在（还有一个非常讽刺的“Ar你错过了一个程序集引用？”）。这让我相信问题必须在构建阶段发生。

因此，我建议构建指向此DLL的任何其他项目，并重新添加其引用。

Answer 6

我们遇到了与WPFToolkit非常相似的问题。我们刚刚升级到2010年2月发布（使用3月5日的msi）。 “添加引用”在正确的位置显示正确的文件，但列出旧版本#s。但是，物理文件具有正确的版本#s。已经卸载，从注册表等手动删除任何WPFToolkit引用，无济于事。它必须在某处缓存这些东西，但我们还没有弄明白。浪费了几个小时。

Answer 7

启用FusionLog，在DLL加载失败后，在文件夹C：\ FusionLog \ Default \ devenv.exe中打开DLL名称的文件。这将显示DLL实际加载的路径。

就我而言，旧版本神秘地出现在

中

C：\ Program Files \ Microsoft Visual Studio 10 \ Common7 \ IDE！

为了阻止这种情况再次发生，我在Common7 \ IDE上为Everyone添加了一个安全规则“Deny Write”。

Answer 8

我遇到的问题与此处描述的类似，只是我对问题的解决方案与我编译代码的方式有关。 build，clean和Rebuild之间有区别。在我的情况下，我只是在我的更改之间使用Build，并且依赖解决方案中的dll没有被转移到设置引用的其他解决方案的所有更改。我通过使用Rebuild解决了这个问题，Rebuild清理，编译和链接所有源文件，无论它们是否发生了变化。然后更新第一个解决方案中的dll并自动复制到第二个解决方案，其中设置了引用并解决了问题。 干杯，我希望这有帮助。

Answer 9

类似的症状 - 问题出现在Project Properties，Reference。中的“Referene paths”中。

此处的完整描述和解决方案： Referenced assemblies automatically replaced by visual studio 视觉工作室/ 22810867＃22810867

Answer 10

查看这些内容：

1. 如果主机Web应用程序及其引用的应用程序都引用了有问题的DLL。例如比如说，您的Web应用程序使用abc.dll（有问题）和另外一个dll xyz.dll（即同时引用abc.dll的类项目）。

在这种情况下，假设您已将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中

希望，上面的细节会有所帮助，祝你好运

Answer 11

一个可能的原因是参考路径。如果有任何对旧dll文件夹的引用，即使添加了新的dll引用，VS也会将其用作主引用。