在部署环境之间管理复杂的 Web.Config 文件 [英] Managing complex Web.Config files between deployment environments
问题描述
有谁知道在不同的构建/部署环境之间管理 Web.Config 文件的任何好的工具/实用程序吗?
例如，我有一个 WCF 项目，在开发中我不想启用 SSL，但我确实希望在生产中启用它.我想要不同的日志设置、不同的数据库连接字符串、不同的错误处理、不同的文件路径......甚至一些不同的 Unity 框架绑定(为单元测试连接模拟而不是用于部署的真实对象).
维护 Web.Config 的各个副本很痛苦，因为添加新的 Web 服务意味着要编辑多个文件并使它们保持同步.
我还注意到，如果您手动过多地使用 Web.Config，如果您尝试使用添加项目"向导来添加一个WCF 的新 Web 服务，因为它必须修改 Web.Config 以添加端点，并且无法再解析它.所以我必须小心不要使现有的 Web.Config 无效.
我还考虑过使用一些正则表达式来进行替换，并在预构建命令中构建一个新的 Web.Config.到目前为止，这似乎是最好的选择......
还有其他想法吗?看起来这应该是一个非常普遍的问题，因为 Web.Config 在开发和生产部署之间可能永远不会相同.
更新:
我决定编写一个快速控制台应用程序，它将获取给定目录中的所有 xml 文件并将它们合并为一个，并且仅包含基于名称的某些文件.
所以我可以在目录中制作:
WebConfig_All
<预><代码><配置><configSections>...</configSections><system.web>...</system.web></配置>connectionStrings_Debug
<预><代码><配置><连接字符串><add name="connstr" connectionString="...dev..."/></connectionStrings></配置>connectionStrings_Release
<预><代码><配置><连接字符串><add name="connstr" connectionString="...prod..."/></connectionStrings></配置>然后运行我的命令行工具，并传入配置(调试、发布、自定义...)它将合并所有以 _All" 或 _
所以现在我有 80% 的 Web.Config 在一个 WebConfig_All 文件中，而 20% 的自定义内容在每个构建配置的单独文件中.然后，我可以在 VisualStudio、NAnt 或任何我想要的地方将我的命令行工具作为预构建任务运行...
我还让我的 XML 合并逻辑足够好来处理以下内容:
<y a="1"><z a="1"/></y></x> 合并
<y a="1"><z a="2"/></y><y a="2"/></x> 结果:
<y a="1"><z a="1"/><z a="2"/></y><y a="2"/></x> 目前看起来不错... :)
<小时>跟进:
这个话题现在有点老了，所以我想指出 VisualStudio 2010 有一个功能可以进行内置的 web.config 转换:http://msdn.microsoft.com/en-us/vstudio/Video/ff801895
当然，在典型的 Microsoft 方式中，仅实现 50% 的任何功能，它仅适用于使用 Web 部署的 Web 项目.有一个插件可以在其他项目中启用转换，位于此处:http://www.hanselman.com/blog/SlowCheetahWebconfigTransformationSyntaxNowGeneralizedForAnyXMLConfigurationFile.aspx
您还可以使用 BuildMaster 之类的工具来管理配置文件(以及构建、测试、数据库)脚本等...)
我们将所有特定于区域的设置拆分到他们自己的配置文件中.在 Web 应用程序的根目录下，我们创建一个 config 文件夹并将区域特定设置放在那里.因此，任何位于 config 根目录下的文件都将被拾取.
我们的 web.config 看起来像:
<预><代码>...<appSettings configSource="configappSettings.config"/><nlog configSource="config log.config"/><应用程序设置><MyApp.UI.Properties.Settings configSource=configSettings.APGUI.config"/><MyApp.BusinessServices.Properties.Settings configSource=configSettings.Business.config"/><MyApp.Auditing.Properties.Settings configSource=configSettings.Auditing.config"/></applicationSettings>...因此，如果我们要部署到发布区域，构建工具将只执行一个操作，将 config 根目录中的文件替换为相应区域文件夹中的文件.文件结构类似于:
添加:这是源代码控制结构的外观，部署的应用程序只有配置目录，没有子文件夹或课程
Root网页配置配置appsettings.config服务配置文件日志配置发布appsettings.config服务配置文件日志配置调试appsettings.config服务配置文件日志配置它非常干净并且受任何自动构建工具(复制/替换文件)的支持.好的副作用是开发人员可以创建不同的风格并将它们保持在源代码控制之下，而不会影响真实"版本.配置.
Does anyone know of any good tools/utilities for managing Web.Config files between different build/deployment environments?
For example, I have a WCF project that in development I don't want to enable SSL, but I do want it enabled in production. I want different logging settings, different DB connection strings, different error handling, different file paths... Even some different Unity framework bindings (wire up mocks for unit testing instead of the real objects for deployment).
Maintaining individual copies of the Web.Config is a pain, because adding a new web service means editing multiple files and keeping them in sync.
I've also noticed that if you muck with the Web.Config too much by hand, Visual Studio will choke if you try to use the "add item" wizard to, say, add a new Web Service for WCF, since it has to modify the Web.Config to add the endpoint,a nd can't parse it any more. So I have to be careful not to invalidate the existing Web.Config.
I also thought about just using some regex to do replacements and just building a new Web.Config in a pre-build command. That seems like the best option so far...
Any other ideas? It seems like this should be a very common issue, since the Web.Config should probably never be the same between development and production deployments.
Update:
I decided to write a quick console app that will take all the xml files in a given directory and merge them into one, and only include certain files based on the name.
So I can make in a directory:
WebConfig_All
<configuration>
<configSections>
...
</configSections>
<system.web>
...
</system.web>
</configuration>
connectionStrings_Debug
<configuration>
<connectionStrings>
<add name="connstr" connectionString="...dev..." />
</connectionStrings>
</configuration>
connectionStrings_Release
<configuration>
<connectionStrings>
<add name="connstr" connectionString="...prod..." />
</connectionStrings>
</configuration>
Then run my command line tool, and pass in the configuration (Debug, Release, custom...)
And it will merge all the files that end in _All" or_<configuration>`.
So now I have 80% of my Web.Config in a single WebConfig_All file, and the 20% custom stuff in separate files per build configuration. I can then run my command line tool as a pre-build task in VisualStudio, or from NAnt, or wherever I want...
I also made my XML merge logic good enough to handle stuff like:
<x>
<y a="1">
<z a="1"/>
</y>
</x>
merge with
<x>
<y a="1">
<z a="2"/>
</y>
<y a="2"/>
</x>
results in:
<x>
<y a="1">
<z a="1"/>
<z a="2"/>
</y>
<y a="2"/>
</x>
Looking good so far... :)
Followup:
This topic is a little old now, so I wanted to point out that VisualStudio 2010 has a feature to do web.config transformations built-in: http://msdn.microsoft.com/en-us/vstudio/Video/ff801895
Of course in typical Microsoft fashion of only implementing any feature 50% of the way, it only works for web projects using web deploy. There is a plugin to enable transformations in other projects, located here: http://www.hanselman.com/blog/SlowCheetahWebconfigTransformationSyntaxNowGeneralizedForAnyXMLConfigurationFile.aspx
You could also use a tool like BuildMaster to manage config files (along with builds, tests, DB scripts, etc...)
We split out all region specific settings into thier own config file. Under the root of the web app we create a config folder and place the region specific settings there. So whatever files are living under the root of config will get picked up.
our web.config looks something like:
.
.
.
<appSettings configSource="configappSettings.config"/>
<nlog configSource="config
log.config"/>
<applicationSettings>
<MyApp.UI.Properties.Settings configSource="configSettings.APGUI.config"/>
<MyApp.BusinessServices.Properties.Settings configSource="configSettings.Business.config"/>
<MyApp.Auditing.Properties.Settings configSource="configSettings.Auditing.config"/>
</applicationSettings>
.
.
.
So if we are deploying to the release region the build tool will just have an action to replace the files in the root of config with the files from the appropriate region folder. The file structure looks something like:
ADDED: This is how the source control structure looks, the deployed app would just have the config dir with no sub folders or course
Root
web.config
Config
appsettings.config
services.config
logging.config
elease
appsettings.config
services.config
logging.config
debug
appsettings.config
services.config
logging.config
It is pretty clean and supported by any automated build tool(copying/replacing files). The nice side effect is that developers can create different flavors and keep them under source control without affecting the "real" configs.
这篇关于在部署环境之间管理复杂的 Web.Config 文件的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
