C# 谁将app.config复制到app.exe.config？

我正在编写一个游戏开发IDE，用于创建和编译.NET项目（我在过去几年中一直致力于此），并正在对其进行更新，以便不仅为Windows/Visual Studio生成输出，而且为Linux/MonoDevelop生成输出（对于.NET来说，这是一个非常简单的过程，但仍需要一些调整）

作为这项工作的一部分，我发现有必要开始生成app.config文件，作为这项工作的一部分，将依赖DLL名称映射到包含元素的Linux依赖名称。我对谁负责将app.config文件复制到输出名app.exe.config感到困惑。在Visual Studio项目中，app.config的生成操作通常设置为“None”，其设置表明它不会被复制到任何地方，但当Visual Studio编译项目时，它会生成app.exe.config（尽管我有时发现这不可靠）。当我使用MSBuild生成由IDE生成的解决方案文件（用于调试目的）时，MSBuild会将app.config复制到app.exe.config。但是，当我使用CSharpCodeProvider.CompileAsemblyFromFile编译项目时，它（自然）不喜欢将配置文件作为源代码包含（“app.config（1,1）：错误CS0116:名称空间不直接包含字段或方法等成员”），当然，当我不将其作为输入包含时，它不会将其复制到输出。我的责任是独立地将app.config复制到app.exe.config，还是有更标准的方法

---

是否硬连线以获取第一个*.config文件？在我的IDE中，可以想象app.config文件将被重命名或添加另一个文件（就像在Visual Studio中一样）。对我来说，IDE对配置文件有这样一个秘密操作似乎有些奇怪（我认为MonoDevelop在这方面的行为类似，因为我在那里也找不到配置文件的特殊操作）。我甚至不知道它是如何选择这个秘密操作适用于哪些文件的。

C#编译器根本不关心配置文件。生成环境（MSBuild和VS）将自行负责复制该文件。

我认为MSBuild负责复制。如果您要挖掘stock.target文件，那么您可能会找到相应的指令。VS本身不会复制

请注意，Visual Studio确实验证配置文件。

顺序：

项目目录中第一个没有生成操作的app.config文件

项目目录中第一个包含内容生成操作的app.config文件

子目录中第一个没有生成操作的app.config文件

子目录中具有内容生成操作的第一个app.config文件

---

msbuild/xbuild还允许您通过设置$（AppConfig）属性来覆盖此属性。

一个稍微技术性的回答-您的项目通过csproj文件中的此键引用Microsoft.CSharp.targets：

<Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />

App.Config文件似乎是作为环境变量传递的（它应该存在，但谁设置了它，我不知道）：

app.config的处理是特殊的，按名称处理，构建过程将按照以下顺序选择app.config文件：


选择主项目中设置的值$（AppConfig）
在与项目相同的文件夹中选择@（无）App.Config
在与项目相同的文件夹中选择@（Content）App.Config
在项目的任何子文件夹中选择@（无）App.Config
在项目的任何子文件夹中选择@（Content）App.Config

我的IDE未使用MSBuild编译项目。它正在使用CSharpCodeProvider。那么我的IDE应该做什么呢？它应该在编译后使用
file.copy
复制配置文件。将第一个*.config文件复制到outputname.exe.config并忽略任何可能的其他*.config文件（不应该存在）？我会将
app.config
复制到
outputname.exe.config
并忽略其他配置文件，您应该使用MSBuild编译项目。这就是VisualStudio所做的（它本身不进行编译）。有许多托管类可供您以编程方式调用MSBuild。为了澄清这一点，我的问题是，因为我使用CSharpCodeProvider编译代码（而不使用诸如MSBuild之类的shell命令编译项目），在输出中获取app.exe.config的正确方法是什么？我建议在IDE中使用MSBuild，并为生成的任何特殊生成输出创建MSBuild任务，而MSBuild不支持这些生成输出。这将使MSBuild能够编译为您的解决方案。此外，这将使您的产品更容易与TeamCity之类的持续集成集成。MSBuild可以编译我的解决方案。当它这样做时，它已经正确地处理app.config了。CSharpCodeProvider似乎是一个更直接的解决方案，其开销比直接使用MSBuild要少。IDE生成一个解决方案文件，但在内部编译时不使用它。请参阅您提到的
$（AppConfig）
属性对我非常有帮助。我觉得你可以通过更多的背景知识来改进这个答案。我找到了一些额外的解释，但如果有官方链接，那就更好了。如果没有，也欢迎只提及
目标
文件。
  <!--
    ============================================================
                                        _CopyAppConfigFile

    Copy the application config file.
    ============================================================
    -->
  <Target
      Name="_CopyAppConfigFile"
      Condition=" '@(AppConfigWithTargetPath)' != '' "
      Inputs="@(AppConfigWithTargetPath)"
      Outputs="@(AppConfigWithTargetPath->'$(OutDir)%(TargetPath)')">

    <!--
        Copy the application's .config file, if any.
        Not using SkipUnchangedFiles="true" because the application may want to change
        the app.config and not have an incremental build replace it.
        -->
    <Copy
        SourceFiles="@(AppConfigWithTargetPath)"
        DestinationFiles="@(AppConfigWithTargetPath->'$(OutDir)%(TargetPath)')"
        OverwriteReadOnlyFiles="$(OverwriteReadOnlyFiles)"
        Retries="$(CopyRetryCount)"
        RetryDelayMilliseconds="$(CopyRetryDelayMilliseconds)"
        UseHardlinksIfPossible="$(CreateHardLinksForAdditionalFilesIfPossible)"
            >

      <Output TaskParameter="DestinationFiles" ItemName="FileWrites"/>

    </Copy>

  </Target>

<ItemGroup>
  <AppConfigWithTargetPath Include="$(AppConfig)" Condition="'$(AppConfig)'!=''">
    <TargetPath>$(TargetFileName).config</TargetPath>
  </AppConfigWithTargetPath>
</ItemGroup>