项目参考 DLL 版本地狱答案

【问题标题】：Project References DLL version hell项目参考 DLL 版本地狱
【发布时间】：2011-01-22 09:12:15
【问题描述】：

我们在让 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，但在该项目引用中它具有旧版本 - 即使路径是正确的。

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

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

有谁知道如何确保最新版本通过（最好是自动或在编译时）。

编辑：

虽然不完全是我正在处理的场景，但我正在阅读 this 文章，并且在某处它提到了 CLR 忽略修订号。可以理解（尽管这在以前不是问题——我们正在修订 39），所以我想我会更新内部版本号，但仍然没有用。尽管我会更新次要版本号并查看是否有任何不同，但我还是徒劳无功。

我并不是说这是答案，因为我必须先检查很多东西，但从表面上看，这似乎解决了我的问题......

进一步编辑：在其他类库中，这似乎已经解决了这个问题，但是在测试 Windows 应用程序中，它仍然通过:(

如果我再次增加次要版本号，同样的问题会再次出现，但我会留下错误的版本。

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

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

帮助！

【问题讨论】：

以任何特定顺序构建项目（例如，BusinessLogic 然后 ReportData）似乎没有帮助。
您是否对作为解决方案一部分的程序集使用文件引用？还是 Connectivity.dll 内置在另一个解决方案中？
这是另一个解决方案的一部分

标签： .net visual-studio-2008 assemblies reference dll

【解决方案1】：

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

【讨论】：

【解决方案2】：

看看这些东西：

如果有问题的 dll 被主机 Web 应用程序及其引用的应用程序引用。例如比如说，您的 Web 应用程序使用 abc.dll（有问题）和 1 个其他 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 中

希望以上细节对你有帮助，祝你好运

【讨论】：

【解决方案3】：

类似的症状 - 问题出在项目属性、参考中的“参考路径”中。

这里有完整的描述和解决方案： Referenced assemblies automatically replaced by visual studio 视觉工作室/22810867#22810867

【讨论】：

【解决方案4】：

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

有可能在一个项目中某个 DLL 不正确，而正是这个不正确的 DLL 被 Visual Studio 提取并使用了。

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

【讨论】：

我认为这是可行的，因为当引用添加到项目（通过 Visual Studio）时，版本元数据记录在 <Reference/> 行中。我正在处理同样的问题，发现卸载项目、查找引用并手动更改版本信息允许项目“找到”较新版本的 DLL。
为我工作，我删除了所有 obj 和 bin 文件夹，删除了项目之间的引用，清理、重建、重新添加了引用。布雅。
为我工作！此外，如果您使用的是发布文件夹，最好在发布之前删除所有内容，以确保文件被添加而不是替换！
@revobtz - 如果您使用文件发布，我认为在设置（文件发布选项）中有一个选项可以自动“在发布前删除所有现有文件”
@MrShoubs 是的，我已经知道了，但有时人们并不知道。所以我只希望他们确保获取新文件而不是替换，但感谢您的评论，它可能会帮助其他人！

【解决方案5】：

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

【讨论】：

【解决方案6】：

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

在我的例子中，一个旧版本神秘地出现在

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

为了阻止这种情况再次发生，我在 Common7\IDE 上向所有人添加了“拒绝写入”安全规则。

【讨论】：

如果您启用了 Fusion 程序集绑定日志记录，请确保在调试完程序集加载问题后将其禁用！
@smirkingman 在我的情况下，它位于C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\root. 下，我从Temporary ASP.NET Files 中删除了所有内容并进行了一个干净的项目，但它仍然试图从同一位置加载。任何想法

【解决方案7】：

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

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

因此，我建议构建指向此 DLL 的所有其他项目并重新添加它们的引用。

【讨论】：

【解决方案8】：

您可以尝试的选项很少。

编译项目并在输出窗口中查看，以验证准确引用它的程序集路径。
在重新编译之前删除 Obj 文件夹。
关闭并重新打开 Visual Studio，因为 VS 有一些奇怪的行为来保持缓存以保存 Dll 引用。
如果您仍然发现问题，请使用此工具检查它真正来自的参考程序集。 Process Explorer。

【讨论】：

我会在风格上投票给这个，但我还没有得到 15 个代表点。 1 - 显示正确的路径 2 - 似乎根本没有任何区别 3 - 已经完成，有时这确实解决了一些编译问题，但不是这个问题 4 - 我找不到进程资源管理器告诉我的位置这个
1.我想我忘了提到这一点，编译并运行应用程序，你可以在输出窗口中看到它是从哪里加载的。 2. 如达林所说，最好保存在共享文件夹中。因此，您可以删除 bin 和 obj 文件夹以始终重新生成可执行文件，以确保我们使用新的应用程序副本运行。 4. 你提到它从某个地方选择了错误的程序集，对吗？使用此工具，您可以在运行时查看应用程序的引用程序集并查看它的加载位置及其版本号等。
5.此外，在记事本中打开您的项目文件，看看是否有任何硬编码的版本号或提示路径。如果是，请删除它们并添加正确的版本号。
有：False..\. .\..\vhc.server.solution\vhc.connections\Tags\v_3_0_0_5\bin\Debug\VHC.Connections.dll 但改变它没有区别
好的，您使用 Process Explorer 实用程序了吗？

【解决方案9】：

您是否尝试将参考添加为项目参考？即添加参考... -> 项目选项卡 -> 选择您的项目

【讨论】：

不幸的是，这在我们的场景中是不可能的，我们必须引用 DLL 文件。（我希望不是这样）

【解决方案10】：

为了避免 dll 地狱，我建议您在项目中创建一个 lib 文件夹并将所有共享程序集放在此文件夹中。接下来，您仅从该文件夹添加引用。这样，您的项目是自包含的，并且您确切地知道它从哪里选择引用。如果您想使用较新版本更新某些程序集，请将其复制到 lib 文件夹并重建您的项目。

还要确保您没有将引用的程序集放入 GAC，因为它们可能会首先被拾取。

【讨论】：

+1, ...并确保在 Visual Studio 中为每个共享引用勾选本地选项。
刚刚尝试过，但它不起作用 - 仍在拉入以前的版本。
这是个好主意，但没用 :( 以前的版本可能从哪些地方获得？我三重检查我复制了正确的文件。
程序集是否列在 Visual Studio 的“添加引用”对话框的 .NET 选项卡中？这与 GAC 不同。如果是这样，即使您通过浏览选项卡引用程序集，VS 也可能使用注册表来查找文件。这花了我几个小时。我真的希望微软能让开发人员完全控制构建，如果没有找到程序集（而不是试图找到它），则构建失败。
如果 GAC 中没有程序集版本，并且您在项目的参考列表中删除了对库的引用并重新添加它以仅指向 /lib 文件夹中的 dll，则除非您没有对解决方案中引用 DLL 的所有项目执行相同的过程，否则版本不可能是该文件夹中的任何内容。每个需要引用该 DLL 的项目都需要使用本地 /lib 文件夹。