.net 如何根据构建配置有条件地部署 app.config？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/350377/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
How to conditionally deploy an app.config based on build configuration?
提问by Anthony Mastrean
I have three custom build configurations { Dev, Qs, Prd }. So, I have three app configs { Dev.config, Qs.config, Prd.config }. I know how to edit the .csproj file to output the correct one based on the current build configuration.
我有三个自定义构建配置 { Dev, Qs, Prd }。所以，我有三个应用配置 { 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>
My problem is, I need to have sixbuild configurations { Dev, Qs, Prd } x { Debug, Release }. I need to support the debug and release settings (optimizations, pdb, etc) for each environment. However, the app config values don't change between debug/release.
我的问题是，我需要六个构建配置 { Dev, Qs, Prd } x { Debug, Release }。我需要支持每个环境的调试和发布设置（优化、pdb 等）。但是，应用配置值在调试/发布之间不会改变。
How do I keep the build script as generic as possible and use only the three app configs? I don't want to hard code too many conditional strings.
如何使构建脚本尽可能通用并仅使用三个应用程序配置？我不想硬编码太多条件字符串。
采纳答案by Brian
Something along the lines of
类似的东西
<PropertyGroup Condition="'$(Configuration)'=='Dev_Debug' OR '$(Configuration)'=='Dev_Release'" >
<CfgFileName>Dev</CfgFileName>
</PropertyGroup>
<!-- similar for Qs & Prd -->
<Target ...>...$(CfgFileName).config...
回答by Steve Severance
We fixed this using the Choose element in the csproj file. We have several different configurations set up so all we do is drop this block into your proj file and you can use VS's Configuration to help you out. I do want to second Rob's advice to move passed app.config. I have been moving in that direction for some time.
我们使用 csproj 文件中的选择元素修复了这个问题。我们设置了几种不同的配置，所以我们所做的就是将此块放入您的 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>
回答by Rob Williams
I suggest that your question reveals that you have outgrown app.config--it is time to move on to a better solution, and to begin addressing some related issues.
我建议你的问题表明你已经app.config过时了——是时候转向一个更好的解决方案，并开始解决一些相关的问题。
For one, you should NEVER automatically deploy a configuration file to production, and you should expect the operations support personnel to vehemently reject any attempt to do so. Of course, if you are the operations support personnel, then you should reject it yourself. Instead, your release should include some instructions for manually updating the configuration file, with a sample for illustration. Production configuration is too important for lesser measures, unless you simply don't value your production system much.
一方面，您永远不应该将配置文件自动部署到生产中，并且您应该期望操作支持人员强烈拒绝任何这样做的尝试。当然，如果你是运维支持人员，那你就自己拒绝吧。相反，您的版本应包含一些手动更新配置文件的说明，并附有示例说明。生产配置对于次要措施来说太重要了，除非您只是不太重视您的生产系统。
Likewise for test and other environments, but to a lesser degree, so you really only need your app.configpopulated for your own development work.
同样对于测试和其他环境，但程度较低，因此您实际上只需要app.config为您自己的开发工作填充。
An option is to embed the multiple configurations into a single app.config, which is reasonable for small, relatively unimportant applications or in early stages of development/release. For example, create a configuration setting called something like target-envthat contains a value that you use in your code to select other configuration settings, such as by prepending the value onto the keys of the other configuration settings.
一种选择是将多个配置嵌入到单个 中app.config，这对于较小的、相对不重要的应用程序或在开发/发布的早期阶段是合理的。例如，创建一个名为 like 的配置设置target-env，其中包含您在代码中用于选择其他配置设置的值，例如通过将值添加到其他配置设置的键上。
My preference is to move past app.configaltogether, or to use it minimally. In this case, I prefer to put just enough configuration data into a file to allow my application/system to connect to its database(s), then I put the remaining configuration details into a special database table for that purpose. This has lots of advantages, such as making the database "aware" of what environment it represents (dev, test, production, etc.) and keeping the configuration and the other data together. The deployment package can then properly be kept dumb regarding configurations and environment differences--the code just accesses its configuration data and acts accordingly, so the same deployment package is good for any environment.
我的偏好是app.config完全过去，或者最少使用它。在这种情况下，我更愿意将足够的配置数据放入一个文件中，以允许我的应用程序/系统连接到它的数据库，然后我将剩余的配置详细信息放入一个特殊的数据库表中。这有很多优点，例如让数据库“知道”它代表什么环境（开发、测试、生产等）并将配置和其他数据保持在一起。然后，部署包可以在配置和环境差异方面适当地保持愚蠢——代码只访问其配置数据并采取相应的行动，因此相同的部署包适用于任何环境。
However, a key success factor to this approach is that your application code must "know" what it expects for configuration and it must "know" to reject an improper/incomplete configuration. This is where you should spend your time, not trying to work around the limits of app.config.
然而，这种方法的一个关键成功因素是您的应用程序代码必须“知道”它对配置的期望，并且它必须“知道”拒绝不正确/不完整的配置。这是您应该花时间的地方，而不是试图解决app.config.
That usually means creating your own class for accessing configuration data, then using that class throughout your application instead. This also leads to many other benefits, such as strongly-typed configuration data: instead of a String, return a DateTime, or a Url, or an Integer, or a Currency, or whatever best fits the configuration data and the application.
这通常意味着创建您自己的类来访问配置数据，然后在整个应用程序中使用该类。这也带来了许多其他好处，例如强类型的配置数据：而不是 a String，返回 a DateTime，或 a Url，或 an Integer，或 a Currency，或最适合配置数据和应用程序的任何内容。
回答by Nimrod Shory
How about using a build server?
Its been a long time since I've worked in .NET but can't you use Hudson(-like) server for managing your build configurations? Isn't it easier?
And what about NAnt? Doesn't it suit your needs?
使用构建服务器怎么样？
自从我在 .NET 中工作已经很长时间了，但是您不能使用 Hudson（类似）服务器来管理您的构建配置吗？不是更容易吗？
那 NAnt 呢？它不适合您的需求吗？
回答by Anthony Mastrean
The last solution I would like to employ is to create 6 app configs, 1 per custom configuration
我想采用的最后一个解决方案是创建 6 个应用程序配置，每个自定义配置 1 个
{ Dev_Debug.config, Dev_Release.config, Qs_Debug.config, ..., Prd_Release.config}.
{ Dev_Debug.config, Dev_Release.config, Qs_Debug.config, ..., Prd_Release.config}。
Although, with that setup, I could maintain the generic build script, using no conditional strings.
虽然，通过这种设置，我可以维护通用构建脚本，不使用条件字符串。
