c# - "Copy Local"是否可传递给项目引用？

Question

写了。拟议的骗局:因为这里的问题提出了与 linked question 相反的问题，所以我宁愿认为它不是骗局。

首先，我确实阅读了 What is the best practice for “Copy Local” and with project references?(还有 this)，无论如何我都必须尝试这个，但是获得对此的一般反馈似乎是必要的，因为关于这个东西的 docs 太可怕了而且我' m 仅在 VS2010 上，也许他们在较新的版本中更改了一些内容，如果知道的话会很高兴。

其次，我只对这个问题的项目 引用 感兴趣，因为我有 read that assemblies from the GAC are handled differently 和GAC 与我的问题无关。

第三，在阅读了建议的骗局之后，但更重要的是@Albireo 提供的漂亮的 answer，看来区分文件 依赖项也很重要，其中依赖项引用一个 dll 程序集文件和 项目 依赖项(即我要问的内容)，其中依赖项引用一个 项目 并隐式地引用该项目的输出文件。

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

• 2个C#可执行项目
• n 个 C# dll 汇编项目
• 这 2 个可执行文件具有不同的输出目录，因为它们将单独部署，这样它们在开发人员机器上也是分开的
• 这 2 个可执行文件依赖于某些 DLL 程序集(它们可能相互依赖)
• 共有三个输出目录:
  • /x1 可执行 1 项目
  • /x2 for executable 2 project
  • /lib 用于所有 dll 程序集

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

2 个可执行项目 已将它们引用的所有 DLL 程序集项目引用的 Copy Local 设置为 true直接复制到/x1 /x2

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

例子:

• x1.csproj(例如 Output = x1/one.exe)
  • 引用:dlA.csproj(例如 Output = lib/a.dll)和 Copy Local = *true*
  • (没有直接引用 b.dll)
• dlA.csproj(例如 Output = lib/a.dll)
  • 引用:dlB.csproj(例如 Output = lib/b.dll)和 Copy Local = **false**<
  • (没有直接引用 c.dll)
• dlC.csproj(例如 Output = lib/c.dll)
  • (没有进一步的相关引用)

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

---

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

Answer 1

it would also appear that it is important to differentiate file dependencies, where the dependency references a dll assembly file and project dependencies (i.e. what I'm asking about), where the dependency references a project and implicitly the output file of that project.

不是真的，不是。

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

如果ProjectA取决于 ProjectB build ProjectA ProjectB必须已经构建(并且是最新的)，MSBuild 然后将提取其 DLL(而不是其 C# 代码)并将其链接到 ProjectA .

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

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

Will the other two dlls also be copied to the output directory?

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

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

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

有了这个依赖链:

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

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

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

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

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

Is this documented somewhere?

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