30

假设我们有一个具有以下结构的解决方案：

  • Project.DAL - 数据访问层，依赖于较低级别的库，例如 Oracle.DataAccess w/copy local = true
  • Project.BLL - 业务逻辑层，引用 Project.DAL 作为项目
  • Project.UI - UI 层，编译为可执行文件，引用 Project.BLL，默认项目

编译 Project.UI 时，VS 足够聪明，可以将 Project.DAL.dll 复制到输出目录，但它不够聪明，无法弄清楚我希望将 Oracle.DataAccess 复制到输出目录以及分发给客户端.

谁能解释为什么会这样？是因为它在 GAC 中看到 Oracle.DataAccess 并假设客户端也会在 GAC 中拥有它吗？

这没什么大不了的，但是每次我添加一个新的程序集引用时，我都必须记住将它设置为复制本地并添加一个项目以在我的构建脚本中复制它，这有点烦人。

4

4 回答 4

31

还有一件事。

当您根本不在代码中使用引用的 DLL时，它将忽略 CopyLocal 并且不会将其复制到您的输出目录。

于 2010-02-14T17:36:31.907 回答
26

是的，Visual Studio 将在以下两种情况中的任何一种情况下将 DLL 复制到输出路径：

  1. DLL 使用 CopyLocal = true 显式引用
  2. DLL 在没有 CopyLocal 的情况下被引用或通过其他一些引用的 DLL 隐式引用，并且不在 GAC 中

当文件在 GAC 中时它不会复制本地的原因是，在解析程序集名称时 GAC 具有最高优先级，即即使您有（不同的）本地副本，也将使用 GAC 的版本。

我建议您设置一个库目录，在其中放置所有引用的外部程序集。然后，您在没有 Oracle 文件 gac'ed（也没有为此安装 Visual Studio）的计算机（或 VM）上设置一个自动 MSBuild 脚本。这样，文件将被复制到构建中，与使用 VS 时相比，您可以更好地控制所做的事情。

于 2009-02-02T16:49:14.863 回答
17

我有一个奇怪的情况，即使程序集是一个项目引用并且在引用属性窗口中显示为“True”的“复制本地”被引用，DLL 没有被复制到输出目录。我在 GAC 中有一个早期版本的 DLL，但我不明白为什么这会阻止 DLL 被复制。

我发现通过卸载项目并手动编辑项目引用 XML 如下：

<ProjectReference Include="..\SomeProject.csproj">
  <Project>{11111111-1111-1111-1111-111111111111}</Project>
  <Name>Some Project Name</Name>
  <Private>True</Private>
</ProjectReference>

DLL 已按预期复制到输出目录。我发现仅在属性窗口中将 Copy Local 设置为 True 意味着该<Private>元素完全丢失，但在将其设置为 false 的情况下，它的值为“False”。

于 2010-05-13T15:47:19.390 回答
3

@RenniePet 这是一个博客链接，该链接描述了上面评论中描述的 RenniePet 方法（如果您不想像 @Shaun 建议的那样手动编辑项目文件）：

http://blogs.msdn.com/b/jjameson/archive/2009/11/18/the-copy-local-bug-in-visual-studio.aspx

于 2013-11-28T23:06:32.973 回答