在开发和生产环境中使用不同的Web.config
我需要在ASP.NET应用程序中使用不同的数据库连接string和SMTP服务器地址，具体取决于它是在开发环境还是在生产环境中运行。
该应用程序通过WebConfigurationManager.AppSettings属性从Web.config文件读取设置。
我使用Build / Publish命令通过FTP将应用程序部署到生产服务器，然后用正确的手动replace远程Web.config。
有没有可能简化部署的过程？ 谢谢！
在Visual Studio 2010及更高版本中，您现在可以根据构buildconfiguration将转换应用于web.config。
创buildweb.config时，可以在解决scheme资源pipe理器中展开该文件，您将看到两个文件：
- Web.Debug.Config
- Web.Release.Config
它们包含可用于的转换代码
- 更改连接string
- 删除debugging跟踪和设置
- 注册错误页面
有关更多信息，请参阅MSDN上Web应用程序项目部署的Web.config转换语法 。
尽pipe官方不支持，也可以将相同types的转换应用于非web应用程序app.config文件。 请参阅Phil Bolduc博客 ，了解如何修改项目文件以向msbuild添加新任务。
这是Visual Studio Uservoice的一个长期的需求 。
Visual Studio 2010及更高版本的扩展 “ SlowCheetah ”可用于为任何configuration文件创build转换。 从Visual Studio 2017.3开始， SlowCheetah已经集成到IDE中 ，代码库由Microsoftpipe理。 这个新版本也支持JSON转换。
web.config中的<appSettings>标记支持一个文件属性，该属性将使用自己的一组键/值来加载外部configuration。 这些将覆盖你的web.config中的任何设置或添加到他们。
我们通过在安装时修改我们的web.config来利用这个优点，使用一个与网站安装环境相匹配的文件属性。 我们通过安装程序上的开关来执行此操作。
例如;
<appSettings file=".\EnvironmentSpecificConfigurations\dev.config"> <appSettings file=".\EnvironmentSpecificConfigurations\qa.config"> <appSettings file=".\EnvironmentSpecificConfigurations\production.config">
注意：
- 由该属性指定的.config的更改不会触发asp.net辅助进程的重新启动
你看过networking部署项目吗？
还有一个VS2005版本，如果你不在2008年。
我也想知道。 这有助于隔离我的问题
<connectionStrings configSource =“connectionStrings.config”/>
然后我保留一个connectionStrings.config以及一个“{host} connectionStrings.config”。 这仍然是一个问题，但是如果您为两个环境中的不同部分执行此操作，则可以部署和版本相同的web.config。
（我不使用VS，顺便说一句。）
我使用NAnt生成脚本部署到我的不同的环境。 我已经通过XPath修改了我的configuration文件，具体取决于它们被部署到的位置，然后使用Beyond Compare自动将它们放到该环境中。
花一两分钟设置，但你只需要做一次。 然后batch file接pipe，而我去另一杯咖啡。 🙂
这是我find的一篇文章。
在一个有4个环境（开发，testing，分期和生产）的项目中，我们开发了一个系统，应用程序根据部署到的机器名称select适当的configuration。
这对我们有效，因为：
- pipe理员可以在不涉及开发人员（需求）的情况下部署应用程序，而无需摆弄他们所憎恨的configuration文件。
- 机器名称遵守惯例。 我们使用正则expression式匹配名称，并将其部署到环境中的多台机器上; 和
- 我们使用集成安全性来连接string。 这意味着我们可以在devise时将帐户名称保存在我们的configuration文件中，而不会泄露任何密码。
在这种情况下，它对我们运作良好，但可能无处不在。
企业库configuration编辑器可以帮助你做到这一点。 它允许你创build一个基本的configuration文件，然后为每个环境增量。 然后，您可以合并基础configuration和增量以创build特定于环境的web.config。 看看这里的信息，可以帮助你更好地完成任务。
你也可以把它做成一个后期制作步骤。 除了debugging和发布之外，还要设置一个“部署”的新configuration，然后将生成后的步骤复制到正确的web.config中。
我们为我们所有的项目使用自动构build，并使用构build脚本更新web.config文件以指向正确的位置。 但是，如果你正在做VS的一切事情，那不会对你有所帮助。
这是使用machine.config的巨大好处之一。 在我上一份工作中，我们有开发，testing和生产环境。 我们可以将machine.config用于连接string（适当的，dev / test / prod SQL机器）。
如果您无法访问实际的生产机器（例如，如果您在共享主机上使用托pipe公司），则这可能不是您的解决scheme。
