Visual Studio 不从间接引用的项目中复制内容文件答案

【问题标题】：Visual studio not copying content files from indirectly referenced projectVisual Studio 不从间接引用的项目中复制内容文件
【发布时间】：2012-09-05 09:01:15
【问题描述】：

我的项目结构如下：

Library1 <--[project reference]-- Library2 <--[ref]-- Executable
--------                          --------            ----------
ContentFile                      .cs files           .cs files
.cs files

所有项目引用的 CopyLocal = true。

当我构建项目时，ContentFile 被复制到Library2 的输出目录，但没有复制到Executable 的输出目录，这意味着应用程序运行时缺少ContentFile 的可执行文件。

为什么内容文件被复制到Library2 的输出目录，而不是Executable 的输出目录？有没有办法将它也复制到后者（我想在没有构建事件的情况下这样做，因为我相信人们会忘记这一点）？

我正在寻找一个合理且可维护的解决方案；在添加新项目或新的间接引用的内容文件时需要最少的努力，因此不太可能简单地忘记这样做。

使用构建后事件（如xcopy ../Library/bin/Debug/SomeDll.dll bin/Debug）；并手动将项目的输出目录设置为$(SolutionDir)/bin/... 而不是默认值（基于每个项目），很快就变得一团糟。在“主项目”中添加内容文件作为链接也太乏味了。如果 C# 的输出文件具有与 Visual C++ 相同的默认设置（即$SolutionDir/$Platform/$Configuration），那会很好，但它没有。

我也考虑过根本不使用标准的 MSBuild 过程并编写自定义构建目标（例如在 Atmel Studio 中使用 gcc），但我并没有走多远。此外，我希望 Visual Studio 的标准“构建”和“调试”命令能够像往常一样工作。

更新：

这里有更多关于我在做什么的细节。

我有一个Executable 项目的解决方案。此外，还有很多项目可以调用Plugins。 Executable 通过托管项目引用引用所有这些 Plugins。

由于插件项目是为可执行文件量身定制的，但可能具有可重用的组件，因此主要功能通常在 External 项目中实现，而 Plugin 项目只是一个包装器（尽管并非总是如此）。

说External 项目有时会使用第三方提供的本地DLL。然后将这些 DLL 作为内容文件添加到 External 项目中，并将 Copy to output dir 设置为 Copy always。所以结构看起来像上图：

External <---------------[is not aware of]--------------------+
--------                                                      |
.cs files <--[reference]-- PluginWrapper <--[reference]-- Executable
"Native DLL"               -------------                  ----------
                           .cs files                      .cs files

奇怪的是，“本机 DLL”被复制到 External 的输出目录（显然），以及 PluginWrapper 的，但不是 Executable's.

然后，开发人员的工作流程是编写一个 External 作为一个完全隔离的实体（它们经常被重用），用 PluginWrapper 包装它，然后只添加对PluginWrapper 到Executable 的项目引用。我觉得很奇怪，这显然是一件不常见的事情。

我认为也许编辑 Executable 的 MSBuild 目标 XML（也包括间接引用的内容文件）可以解决问题。

我可能希望按照建议将 DLL 作为嵌入式资源添加到项目中，但是像这样嵌入本机 DLL 对我来说似乎很奇怪。最后，正如 Brenda Bell 所建议的那样，通过从上图中删除“[不知道]”并添加对 External 的项目引用来更改开发人员的工作流程可能是最明智的解决方案，即使并不理想。

更新 2

请注意，嵌入式资源的想法可能并不适用于所有情况。如果需要在可执行文件的目录中放置依赖项（不是 cwd 或任何东西），那么这可能无法正常工作，因为安装文件夹中缺少管理员权限（从嵌入式资源中解压缩文件）。听起来很奇怪，但这是我们使用的第 3 方库之一的严重问题。

【问题讨论】：

您能否更具体地说明您已经考虑/放弃了哪些解决方案？如果有人向您建议您出于某种原因已经拒绝自己的事情，那将是浪费时间。
@JensH 对不起，我忘了补充。使用构建后事件；并手动将项目的输出目录设置为$(SolutionDir)/bin/... 而不是默认的（基于每个项目），很快就变得一团糟。在“主项目”中添加内容文件作为链接也太乏味了。
您是否尝试过将所有三个项目放在同一个解决方案中，并根据需要设置它们的项目依赖关系？
@StarPilot 是的，这正是我在问题中描述的情况。由于某种我不知道的原因，它不起作用。
您也可以将所有内容放在一个单独的项目中，并在需要的地方引用它。不过，我仍然会使用嵌入式资源。

标签： c# .net visual-studio projects-and-solutions

【解决方案1】：

将 Library1 引用添加到可执行项目。

【讨论】：

我更喜欢完全透明模块的想法，因此，发现 EmbeddedResource 的想法很有趣，但从长远来看，我觉得这是最明智和实用的方法。不过，我仍然觉得奇怪的是 VS 没有将所有内容文件都放在主项目的输出目录中。
我最终使用了不同的解决方案。我的资源文件是模板（cshtml 文件），我真的很想将它们保存为物理文件，以便于编辑并且您可以进行语法检查。我刚刚从另一篇文章中发现，您可以将它们添加为项目资源文件（右键单击项目、资源、添加现有文件）。现在我可以从代码中访问和读取它们了！所以在我的情况下，我相信其他人，这是一个很好的解决方案。将它们作为资源后，您可以像这样读取它们：System.Text.Encoding.UTF8.GetString(Resources.YourResourceFilename);
@dialer：我也觉得很难理解（为什么 VS 会这样）。 stackoverflow.com/a/7306075 有助于理解。
IMO，这个答案更像是一个“快速修复”而不是一个实际的解决方案。我遇到了同样的问题，我没有更好的答案，但是这个修复很丑。
今天我正把头撞在墙上 WRT 这个问题。我最终在 MSBuild 的 GitHub 存储库中遇到了这个未解决的问题，我认为这是问题的症结所在：github.com/Microsoft/msbuild/issues/1054

【解决方案2】：

编辑：

您可以将所有内容放在单独的项目中，将其所有条目设置为“内容”和“始终复制”，并从外部和可执行文件中引用该项目

-

IMO 您正在寻找嵌入式资源，而不是内容文件。

当您编译库 1 时，内容文件被放置在其 bin 文件夹中。编译库 2 时，编译器会识别引用的代码并包含它（库 1.dll），但无法识别内容文件，因为它们在库 2 中的任何地方都没有提及。将库 2 链接到可执行文件时也是如此。

如果您的内容文件相对较小（图标、模板等），并且您不希望在丢失源代码的情况下对其进行编辑，那么您可以将它们作为资源嵌入并提供一个公共方法来返回内容，如：

 public static Stream GetResourceContent(string rName){
     string resName = System.Reflection.Assembly
         .GetExecutingAssembly().GetManifestResourceNames()
         .FirstOrDefault(rn => rn.EndsWith("."+rName));
    if(resName!=null)
        return System.Reflection.Assembly.GetExecutingAssembly().GetManifestResourceStream(resName);
    else
        return null;
}

如果您的内容必然会发生变化，例如模板等，那么请考虑在可执行项目中包含一份副本

【讨论】：

【解决方案3】：

另一种选择是将 ContentFile 作为资源嵌入到 Library1 程序集中，并使用 Assembly.GetManifestResource() 提取它。

http://blogs.msdn.com/b/alexdan/archive/2007/12/19/loading-embedded-resources-in-c-using-getmanifestresourcestream.aspx

【讨论】：

【解决方案4】：

Brenda 的答案的一个变体是将 Library1 的内容文件添加为可执行项目中的链接。您仍然拥有项目中的条目，但您不需要管理每个文件的多个副本。

【讨论】：

【解决方案5】：

可能是您仅从 XAML 文件中引用 Library1，在这种情况下，Visual Studio 无法识别该用法。在代码中添加引用，例如通过应用名称属性

【讨论】：