0

我有一个最近开始维护的现有项目，在更新其中一个类库所依赖的几个程序集时，我遇到了一些我不太了解的东西。

  • 需要更新 2 个程序集，NuGet 最初都没有跟踪
  • 程序集 A 在 NuGet 上不可用，必须手动下载和引用。我将它解压缩到我的桌面，删除了旧参考，并使用“添加参考>浏览”添加了新参考
  • 程序集 B 可通过 NuGet 获得，因此我删除了旧引用，然后使用包管理器将其添加回来。
  • 两个引用都将“本地复制”设置为 true
  • 在为调试和发布配置构建时，dll 被复制到项目下各自的 bin 文件夹中。
  • 此时，我删除了桌面上的程序集 A 的 dll，引用路径现在指向..\solution\project\bin\Debug\assemblyA.dll使用 Debug 配置和..\solution\project\bin\Release\assemblyA.dll使用 Release 配置时的位置。
  • 程序集 B 存在...\solution\packages\[packagepath]\assemblyB.dll于其各自的 Debug 和 Release bin 文件夹下，但引用路径指向 NuGet 包文件夹中的原始副本。

现在这里的事情对我来说有点模糊。就这样我对此非常清楚并且不做任何假设，我最初的澄清问题是 - 在上述情况下将 Copy Local 设置为 true 时，引用了哪个 - 原始副本或 bin/[配置] 副本？

排序后，我遇到的真正问题是，在为 Release 配置重建解决方案时，它会清除我本地的 assemblyA.dll 副本。对于调试配置，这不会发生。为什么会这样？我错过了一个设置还是这是设计使然？如果这是设计使然，为什么构建之间的行为差​​异以及那时复制本地设置的意义何在？

4

2 回答 2

4

并且引用路径现在指向 ..\solution\project\bin\Debug\assemblyA.dll

这是问题所在。当您调试应用程序时，CLR 只会在两个位置查找 DLL。它将首先在 GAC 中查找，然后在与您的 EXE 相同的目录中。因此它永远不会在您的桌面上找到程序集 A，也不会在包子目录中找到 NuGet 程序集 B，并且您的程序将无法运行。

Copy Local 旨在解决此问题，当您添加对未存储在 GAC 中的 DLL 的引用时，它会自动设置为 True。.NET Framework 程序集始终为 False，A 和 B 程序集为 True。

那么问题出在您首先添加了对桌面上 DLL 的引用。然后您构建了您的应用程序并在 bin\Debug 目录中获得了一份副本。然后，您删除了桌面上的原始文件，并将引用更改为您剩下的唯一一个，即 bin\Debug 中的那个。

这工作了一段时间。直到您使用 Build + Clean 或 Build + Rebuild。清空构建目录的命令。现在您的参考程序集已​​经消失了。

您应该做的是将其复制到更好的位置。项目目录当然是一个好目录。或者它的子目录，就像 NuGet 一样。

于 2013-08-23T15:43:38.823 回答
0

根据我的理解，将 Copy Local 设置为 true，您将始终将程序集放在 bin 文件夹中，无论是调试还是发布。如果您在发布模式下编译，您还必须在文件夹中有 dll，它们没有理由被清除。

我刚刚做了一个测试来验证这种行为。

也许您已经这样做了，但我建议您仔细检查您的引用是否设置为 Copy Local = True。

问候，

于 2013-08-23T15:09:15.443 回答