项目引用的“复制本地”是否可传递？

Question

写。提议的骗子：由于这里的问题与linked question相反，我宁愿认为它不是骗子。

首先，我确实阅读了What is the best practice for “Copy Local” and with project references?（也有this），无论如何我都必须尝试一下，但是获得对此的一般反馈似乎是必要的，因为docs 对此东西太可怕了，我只在 VS2010 上，也许他们在新版本中改变了一些东西，很高兴知道。

第二，我只对这个问题的 project 参考感兴趣，因为我已经 read that assemblies from the GAC are handled differently 和 GAC 无关我的问题。

第三，在阅读了建议的欺骗之后，但更重要的是 @Albireo 在这里的 answer，区分 file 依赖项似乎也很重要，其中依赖项引用了一个 dll 程序集文件和 project 依赖项（即我要问的），其中依赖项引用了一个 project 并隐式地引用了该项目的输出文件.

无论如何，情况就是这样，我觉得有点奇怪，但仍然：

• 2 个 C# 可执行项目
• n C# dll 程序集项目
• 这 2 个可执行文件具有不同的输出目录，因为它们将单独部署，因此它们在开发人员计算机上也是独立的
• 这 2 个可执行文件依赖于某些 DLL 程序集（它们可能相互依赖）
• 共有三个输出目录：
  • /x1 用于可执行 1 项目
  • /x2 用于可执行 2 项目
  • /lib 用于所有 dll 程序集

DLL 程序集所有都将Copy Local设置为false，用于它们的项目引用，因为它们都构建到相同的输出目录。

这2个可执行项目已将它们直接引用的所有DLL程序集项目引用的Copy Local设置为true，以便将DLL复制到@分别为 987654336@/x2。

问题现在是 wrt。到可执行项目不直接引用但仅通过引用程序集传递的DLL：Will程序集，仅当“复制本地”在第一个程序集上设置为 true 时，通过另一个程序集传递引用，复制到可执行文件的输出文件夹？

例子：

• x1.csproj（例如输出 = x1/one.exe）
  • 参考：dlA.csproj（例如输出 = lib/a.dll）和Copy Local = *true*
  • （没有直接引用 b.dll）
• dlA.csproj（例如输出 = lib/a.dll）
  • 参考：dlB.csproj（例如输出 = lib/b.dll）和Copy Local = **false**
  • （没有直接引用 c.dll）
• dlC.csproj（例如输出 = lib/c.dll）
  • （没有进一步的相关参考资料）

因此，我们有一个one.exe -> a.dll -> b.dll -> c.dll 的逻辑依赖关系，其中只有a.dll 显然被复制到one.exe 的输出目录。 其他两个 dll 是否也会被复制到输出目录？ 这是否记录在某个地方？

---

而且，是的，我试过了。而且，是的，它似乎可以工作，但我还没有足够努力地戳它，无论如何，我可能错过了更多的东西。 （还有任何官方文档的问题。）

Answer 1

似乎区分文件依赖项也很重要，其中依赖项引用 dll 程序集文件和项目依赖项（即我要问的），其中依赖项引用项目并隐含地输出该文件项目。

不是真的，不。

MSBuild 并不真正关心引用是指向解决方案中的另一个项目还是指向 DLL。

如果 ProjectA 依赖于 ProjectB 来构建 ProjectA ProjectB 必须已经构建（并且是最新的），那么 MSBuild 将提取其 DLL（而不是其 C# 代码）并将其链接到 @ 987654325@.

为方便起见，添加项目引用而不是 DLL 是“语法糖”：这样 MSBuild 知道它必须选择引用项目的输出，无论输出是什么。

否则，您将不得不手动预构建依赖项，找到它的 DLL 并将其链接到项目，每当您切换构建配置、移动或重命名时都重复该过程。不太实用。

另外两个dll也会复制到输出目录吗？

如果直接从引用程序集的项目中使用依赖项中的任何类型的元素，则将复制该引用。

一个例子可能是这个解决方案布局：

• 我的解决方案
• MySolution.ConsoleApplication
• MySolution.FirstDependency
• MySolution.SecondDependency
• MySolution.ThirdDependency
• MySolution.FourthDependency

有了这个依赖链：

• MySolution.ConsoleApplication
• MySolution.FirstDependency
  • MySolution.SecondDependency
    • MySolution.ThirdDependency
    • MySolution.FourthDependency

如果您构建此解决方案，您会注意到在MySolution.ConsoleApplication 输出目录中将有MySolution.FirstDependency、MySolution.SecondDependency 和MySolution.ThirdDependency 的DLL，但没有MySolution.FourthDependency 的DLL。

为什么会这样？ 当 MSBuild 构建 MySolution.SecondDependency 时，它注意到有一个声明为 MySolution.FourthDependency 的依赖项，但是由于它在 MySolution.SecondDependency 代码中找不到来自 MySolution.FourthDependency 的任何元素的任何用法，它决定执行一些“优化”并从输出中省略 MySolution.FourthDependency 程序集。

过去，当我通过 NuGet AutoMapper 添加到“深度依赖项”时，同样的问题困扰着我：添加 AutoMapper 会添加两个程序集引用，AutoMapper 和 AutoMapper.Net4，其中第二个程序集由第一个程序集通过反射加载当它需要对 .NET Framework 4 引入的新集合对象执行某种操作时。由于第二个程序集是通过反射加载的，MSBuild 认为它没有被使用，因此不必费心复制它。

所以，是的，只要您直接使用它们，它们就会被复制，而不是通过反射。

这是否记录在某处？

这种行为似乎是 MSBuild 的一个“特性”，当我遇到这个问题时，我设法找到了 Microsoft 一些人的博客文章，但现在我找不到了。

Answer 2

它非常简单，与复制本地没有任何关系。 MSBuild 在程序集的元数据中查找程序集的依赖项。你也可以在程序集上运行 ildasm.exe 并双击 Manifest。一定要试试这个以获得洞察力。您将看到 .assembly 指令。由编译器在构建程序集时插入，只会列出您在代码中实际使用的引用程序集。

如果 MSBuild 可以在同一目录中找到这样的程序集，那么它将自动复制它。如果没有，那么它将静默跳过副本。

由此，您可以推断出故障模式。它不能复制非托管 DLL，它们不会出现在元数据中。它无法通过 Assembly.Load/From() 复制您间接依赖的程序集，它们也不会出现在元数据中。它无法复制尚未构建的程序集，这是构建顺序问题。它不能复制您设置为 False 的 Copy Local 属性的程序集。如果程序集存在于 GAC 中，这通常是一个有效的选择，不需要副本。

对于需要帮助的这种情况，构建后事件中的 XCOPY 可以完成工作。