Question

我有三个自定义构建配置{Dev，Qs，Prd}。所以，我有三个app配置{Dev.config，Qs.config，Prd.config}。我知道如何根据当前的构建配置编辑.csproj文件以输出正确的文件。

<Target Name="AfterBuild">
   <Delete Files="$(TargetDir)$(TargetFileName).config" />
   <Copy SourceFiles="$(ProjectDir)$(Configuration).config" DestinationFiles="$(TargetDir)$(TargetFileName).config" />
</Target>

我的问题是，我需要六个构建配置{Dev，Qs，Prd} x {Debug，Release}。我需要支持每个环境的调试和发布设置（优化，pdb等）。但是，app config值在调试/发布之间不会改变。

如何使构建脚本尽可能保持通用，并仅使用三个应用程序配置？我不想硬编码太多的条件字符串。

Answer 1

我们使用csproj文件中的Choose元素修复了这个问题。我们设置了几种不同的配置，因此我们所做的就是将此块放入您的proj文件中，您可以使用VS的配置来帮助您。我想让Rob的建议继续通过app.config。我已经朝这个方向走了一段时间。

  <Choose>
<When Condition=" '$(Configuration)' == 'Debug' ">
  <ItemGroup>
    <None Include="App.config" />
    <None Include="Release\App.config" />
  </ItemGroup>
</When>
<Otherwise>
  <ItemGroup>
    <None Include="Release\App.config">
      <Link>App.config</Link>
    </None>
  </ItemGroup>
</Otherwise>

Answer 2

的内容

<PropertyGroup Condition="'$(Configuration)'=='Dev_Debug' OR '$(Configuration)'=='Dev_Release'" >
    <CfgFileName>Dev</CfgFileName>
</PropertyGroup>
<!-- similar for Qs & Prd -->
<Target ...>...$(CfgFileName).config...

Answer 3

我建议您的问题显示您已经过时app.config - 是时候转向更好的解决方案，并开始解决一些相关问题。

首先，您不应该自动将配置文件部署到生产环境中，并且您应该期望操作支持人员强烈拒绝任何尝试这样做的操作。当然，如果您是运营支持人员，那么您应该自己拒绝。相反，您的版本应包含一些手动更新配置文件的说明，并附有示例说明。生产配置对于较小的措施来说太重要了，除非您根本不重视生产系统。

同样对于测试和其他环境，但程度较小，因此您实际上只需要为自己的开发工作填充app.config。

一个选项是将多个配置嵌入到单个app.config中，这对于小的，相对不重要的应用程序或在开发/发布的早期阶段是合理的。例如，创建一个名为target-env的配置设置，其中包含您在代码中用于选择其他配置设置的值，例如将值预先添加到其他配置设置的键上。

我的偏好是完全超过app.config，或者最低限度地使用它。在这种情况下，我更喜欢将足够的配置数据放入文件中以允许我的应用程序/系统连接到其数据库，然后为此目的将剩余的配置详细信息放入特殊的数据库表中。这具有许多优点，例如使数据库“了解”它所代表的环境（开发，测试，生产等）并将配置和其他数据保持在一起。然后，部署包可以在配置和环境差异方面保持愚蠢 - 代码只是访问其配置数据并相应地执行操作，因此相同的部署包适用于任何环境。

然而，这种方法的一个关键成功因素是您的应用程序代码必须“知道”它对配置的期望，并且它必须“知道”拒绝不正确/不完整的配置。这是您应该花时间的地方，而不是试图在app.config的范围内工作。

这通常意味着创建自己的类来访问配置数据，然后在整个应用程序中使用该类。这也带来许多其他好处，例如强类型配置数据：而不是String，返回DateTime，或Url，或Integer，或者a Currency，或最适合配置数据和应用程序的任何内容。

Answer 4

使用构建服务器怎么样？
自从我在.NET工作了很长一段时间后你不能使用Hudson（类似）服务器来管理你的构建配置吗？是不是更容易？
那个NAnt怎么样？它不适合你的需求吗？

Answer 5

我想采用的最后一个解决方案是创建6个app配置，每个自定义配置1个

{Dev_Debug.config，Dev_Release.config，Qs_Debug.config，...，Prd_Release.config}。

虽然通过该设置，我可以维护通用构建脚本，不使用条件字符串。

如何根据构建配置有条件地部署app.config？

5 个答案: