我想知道引用的 copy-local=true 到底是做什么的。它是否将引用的程序集及其所有依赖项复制到输出目录？
我的场景如下：我有一个使用 log4net 的自定义日志包装器。我构建了一个 MyLogWrapper.dll 的发布程序集，其中 log4net.dll 引用设置为 copy-local true。从 MyProject 引用 MyLogWrapper.dll 并将本地复制设置为 true 应该会导致 log4net.dll 也被复制，对吗？我只在 MyProject 中引用 MyLogWrapper.dll 而没有它的依赖项。log4net.dll 没有被复制到 MyProject 输出目录，但 MyLogWrapper 的所有其他依赖项都是。可能是什么问题呢？
我做了更多的实验，似乎如果我从 GAC 中删除程序集（log4net.dll），它就会开始在本地复制。谁能确认这是问题所在？
不幸的是，根据MSDN 文档中的以下声明，对于 GAC 中已经存在的程序集，CopyLocal 功能似乎无法正常工作。
如果您部署的应用程序包含对在 GAC 中注册的自定义组件的引用，则无论 CopyLocal 设置如何，该组件都不会随应用程序一起部署。在 Visual Studio 的早期版本中，您可以在引用上设置 CopyLocal 属性以确保部署程序集。现在，您必须手动将程序集添加到 \Bin 文件夹。这使所有自定义代码都受到审查，从而降低了发布您不熟悉的自定义代码的风险。
更多信息可以在以下页面中找到，该页面解释了有关项目引用如何工作的详细信息。
在此处在 MSDN 上提出此问题后- 似乎这种行为是设计使然。“如果您部署/复制包含对在 GAC 中注册的自定义组件的引用的应用程序，则无论 Copy Local 设置如何，该组件都不会随应用程序一起部署/复制。”
有一个技巧：将引用 Copy Local 设置为 false，然后再设置为 true，Visual Studio 会自动为该引用添加 Private 元数据。至少 VS 2010 可以。我最近这样做是为了解决我们的 TFS 构建服务器的一个问题，由于某种奇怪的原因，在 GAC 中安装了许多企业库组件，因此在从 TFS Drop 文件夹部署我们的项目时遇到了重大问题。那个假/真把戏救了我们。
你需要对本地复制有点警惕，因为它过去已经让我失望了！
只是偶尔，对于特定的 .dll，它会默默地无法将其复制到构建文件夹。通常这不会出现在开发机器上，因为 dll 通常也在 GAC 中（如果您安装了用于开发的开发工具/库），因此在分发/捆绑之前您不会注意到进入安装程序，并且客户端计算机上缺少所需的文件。
关于这个错误的信息不多，但这个线程为一个特定的库演示了它：here。
被这个抓住后，我认为（通常在任何情况下）确切地知道您的项目需要哪些程序集并拥有一个脚本或类似的自动化操作来确保所有必需的组件都存在是一个好主意，无论是在您构建时，或者更有可能在您制作安装程序或收集文件以进行分发时，
当 local copy 设置为 true 时，它会将属性 local copy = tue 的所有程序集复制到应用程序的 bin 目录中。
在您的情况下，dll 可能正在使用另一个 dll，因此它也需要。
我发现如果引用的项目依赖于 GAC 程序集，则在 Visual Studio 2015 中，项目引用不再尊重这一点。GAC 程序集总是被复制到根项目输出中，并且 copy local = false 仅在项目的输出中包含对 GAC dll 的引用时才受到尊重。