管理 web.config 文件
我有 3 个环境：.NET 4 上的 Dev、QA、Prod。每个环境都有一个唯一的 web.config 文件。我们在管理所有三个版本时遇到了问题。在 TFS 中手动合并 web.config 文件时，很容易忽略一些关键的东西。我们不止一次地得到一个指向 Prod 上的 QA 的连接字符串。
所以，我阅读了在 web.config 转换上。 这些似乎需要 MSBUILD。我们没有构建服务器，所以我不确定如何尝试使用这个解决方案。有没有办法让转换与普通的网络发布一起工作？
对于管理 3 个 web.config 文件，您有其他建议吗？
I have 3 environments: Dev, QA, Prod on .NET 4. Each has a unique web.config file. We have been having problems managing all three versions. Its easy to overlook something critical when manually merging web.config files in TFS. More than once we have ended up with a connection string pointing to QA on Prod.
So, I read up on web.config transformations. These appear to require MSBUILD. We have no build server so I'm not sure how I can attempt to use this solution. Is there a way to make transformations work with a normal web publish?
Do you have any alternative suggestions for managing 3 web.config files?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
当然，请查看此 MSDN 链接。您不需要 MSBUILD。您可以在单独的配置文件中为各种环境设置连接字符串。例如，您可以拥有 Web.config、Web.QA.config 和 Web.Prod.config，其中 QA 和 Prod 是分开的 Visual Studio 构建配置。
或者，您可以只使用默认添加的构建配置：Web.config（本地开发）、Web.Debug.config（用于 QA）和 Web.Release.config（用于生产）。
以此设置为例，Web.config 将具有所有配置，Web.Debug.config 将仅具有针对该环境更改的配置（连接字符串、应用程序设置等），而 Web.Release.config 仅具有配置会因环境而改变。
设置好配置和转换后，您只需更改构建配置，从 Visual Studio 进行构建和发布。
Absolutely, take a look at this MSDN link. You do not need MSBUILD. You can set your connection strings for your various environments in separate config files. For example, you could have Web.config, Web.QA.config, and Web.Prod.config, where QA and Prod are separate Visual Studio Build configurations.
Alternatively, you could just use the build configurations that are added by default: Web.config (local development), Web.Debug.config (use for QA), and Web.Release.config (use for production).
Using this setup as an example, Web.config would have all configuration, Web.Debug.config would have only the config that changes for that environment (connection strings, app settings, etc), and Web.Release.config has only the config that changes for that environment.
Once your configs and transformations are setup, you just change your build configuration, build and publish from Visual Studio.
是的，不要管理它们。我们管理得越少，犯错误的机会就越少。为您的所有环境提供完全相同的 web.config 文件。到处部署相同的分布式包。
所有环境特定的键（例如基本 URL、连接字符串等）都可以在 machine.config 中定义，您只需在每台服务器上部署一次并在所有应用程序中重复使用。或者位于 IIS 站点根目录下的
web.config，所有应用程序均源自该站点。Yes, don't manage them. The less we manage, the less chances of making mistakes. Have exactly the same web.config files for all your environments. Same distributive package deployed everywhere.
And all environment specific keys such as base urls, connection strings, ... could be defined in
machine.configwhich you deploy only once on each server and reused from all your applications. Or aweb.configat the root of your IIS site which all applications would derive from.如果您使用 websetup 项目创建 msi，则可以将自定义安装程序类添加到 websetup。这将为您提供创建预定义批处理脚本的选项，这些脚本将正确设置 web.config 中的值
这是一些带有旧示例的页面
在此处输入链接说明
If you use a websetup project to create an msi, you could add a custom installer class to websetup. This would give you the option of creating pre-defined batch scripts that would properly set the values in the web.config
Here's some page with an old example
enter link description here
另一种方法是创建移动您的设置，并将其更改为外部文件和文件。使用 configSource 属性将该文件链接回来。对于不同的部分，您可以将其放入外部文件中。
然后，您可以拥有单独命名的文件，例如 dev.config、qa.config、live.config 等。更改 web.config 中的名称，或者有 1 个文件，称为environment.config &你永远不会在环境之间合并它。
缺点是整个设置部分必须移到文件中。
西蒙
An alternative is to create move your settings that change into an external file & link that file back in using the configSource attribute. For sections that differ you put that in an external file.
You can then either have separately named files, eg dev.config, qa.config, live.config & change the name in the web.config, or have 1 file say called environment.config & you never merge it between environments.
The downside is the whole setting section has to be moved into the file.
Simon