区分开发、登台和生产环境之间的 web.config答案

【问题标题】：Differentiating web.config between dev, staging and production environments区分开发、登台和生产环境之间的 web.config
【发布时间】：2010-11-27 05:30:09
【问题描述】：

在处理环境之间的 web.config 设置差异方面，有人有什么好的技巧吗？我考虑在我们的源代码控制系统中但在 Web 层次结构之外创建一个“配置”文件夹，并让部署过程复制适当的配置文件（web.dev.config、web.staging.config、web.production.config ) 在部署时放入 web 文件夹。我还看到了有关如何在应用启动时以编程方式更改配置设置（WCF 端点、连接字符串等）的帖子。

什么被认为是最佳实践，每个人在使用这些或其他方法时都有哪些经验？

2010 年 9 月更新

值得注意的是，Visual Studio 2010 通过web.config transforms 添加了此功能。当您使用构建配置管理器 (Build|Configuration Manager...) 为您的项目创建不同的配置（例如，Debug、Dev、Staging 和 Release）时，VS 会将 web.*.config 文件添加到解决方案中。默认 web.config 包含您将用于调试的基线设置。 web.release.config、web.staging.config 等包含 XSLT 转换，每当您基于活动构建配置发布项目时，这些转换都会应用。

【问题讨论】：

见stackoverflow.com/questions/305447/…
@PhilPursglove 这对企业库配置非常有用，但据我所知，它对其他配置设置没有帮助。环境之间的变化比连接字符串和数据库相关属性要多得多。

标签： asp.net deployment configuration web-config

【解决方案1】：

我使用 CruiseControl.NET/NAnt，NAnt 有一个 XMLPoke 任务，允许您在构建时进入并使用 XPath 查询更改任何配置设置。

所以在我的每个构建目标（DEV、UAT、STAGING 等）中，我设置了一堆属性，然后调用主构建目标。主构建目标将所有属性的值和 XMLPokes 放入配置并构建。

【讨论】：

这就是我所做的，但我使用 MSBuild 和 MSBuild 社区任务来编辑 XML，而不是 NAnt

【解决方案2】：

我见过并使用过的一种方法是在 web.config 中设置密钥以按名称区分计算机。

例如：

<add key="comp1.Environment"       value="DEV"/>
<add key="compdb1.Environment"     value="PROD"/>
<add key="compstage.Environment"    value="STAGE"/>

显然 comp1、compdb1 是实际的计算机名称。

然后你会设置类似的东西：

<add key="KeyName,DEV"   value="DevEnvironmentValue"/>

在您的代码中，您需要检查应用程序运行的环境，然后获取适当的密钥，例如。

private string GetKeyValue() {
    string machineName  = String.Concat(System.Environment.MachineName, ".Environment");
    string environment  = ConfigurationManager.AppSettings[machineName];
    string key          = String.Concat("KeyName", ",", environment);
    string keyValue       = ConfigurationManager.AppSettings[key];

    return keyValue;
}

【讨论】：

【解决方案3】：

有一个名为 Web Deployment project 的项目类型，可从 Microsoft 免费获得，让您可以完全做到这一点。您可以根据您的解决方案配置（调试、发布等）替换 web.config 的部分。我们使用了一年多，并且效果很好。它适用于 VS2005 和 VS2008。

希望这会有所帮助

【讨论】：

好点。但是 - 这对 winforms 和 Windows 服务应用程序（即 app.config 文件）有帮助吗？
可能不是因为这种项目使用了ASP.Net编译器，并且绑定了一个web应用项目。

【解决方案4】：

我的方法是拥有多个配置文件。我将所有与环境无关的东西（即无论是开发、登台还是生产都无关紧要）放在 web.config 文件中。任何特定于环境的内容（即数据库连接信息、日志记录、调试设置等）我都放入特定于环境的 local.config 文件中。然后，您可以使用 configSource (http://weblogs.asp.net/fmarguerie/archive/2007/04/26/using-configsource-to-split-configuration-files.aspx) 在 web.config 中包含 local.config 设置

然后可以将 Web.config 检入源代码管理。不要签入 local.config 文件 - 这会迫使您在部署脚本中部署正确的文件。

【讨论】：

【解决方案5】：

虽然其他一些答案可能更合适，但我会在 2007 年添加 Matt Berseth rolled his own method...

总之，他将所有因环境而异的值保存在专有文本文件中，并在构建过程中使用自定义工具将值合并到 .config 文件中。

在对该帖子的评论中，Doron Yaacoby 还 cmets：

"MSBuild 社区中有一个任务可以实现这一点的任务（以及更多）为你，这叫做 XmlMassUpdate。 Ive written about it in my blog"

【讨论】：

【解决方案6】：

使用新的 VS，您可以使用 Web 配置转换。

在此处阅读更多信息：http://msdn.microsoft.com/en-us/library/dd465326.aspx

【讨论】：

我认为应该使用这个
当你意识到你不想存储密码是你的回购时，我总是觉得很好。总之 - 不行。

【解决方案7】：

您需要为一个环境安装，而不是为一个环境构建。在现实世界中，您必须在产品中安装在 QA 中测试过的内容，不允许重新构建。至少在我的世界里是这样的。

【讨论】：

理论上是的。在现实中，或“真实世界”中，QA 和生产之间存在差异。由于服务器名称和凭据不同，即使是像连接字符串这样简单的东西也需要不同的配置。配置转换是有原因的。该构建是离线构建的，但它仍然是为目标环境量身定制的。

【解决方案8】：

下面介绍如何在 VS2012 中添加可针对您的部署环境自定义的不同配置

鼠标右键单击解决方案并选择配置管理器
单击配置管理器按钮
在“配置”列下，针对项目选择组合框您要添加配置并选择
创建一个名为 TEST 的新配置并复制设置从发布并选中创建新的解决方案配置复选框
在 Web.config 上单击鼠标右键
添加配置转换
然后你会得到一个额外的 web.config 例如 web.TEST.config

在此之后，您需要使用特定于您的 TEST 环境的一些转换来修改 web.TEST.config

【讨论】：

【解决方案9】：

简单的方法是有一个枚举，然后有一个基于服务器名称的 switch 语句（如果它的稳定名称）。

如果您需要获取详细信息，请致电 GetURIPath()，这里我给出了使用 url 的示例：

public class StaticData
{
    public enum enumEnvironment
    {
        envNONE = 0,
        envLOC = 1,
        envDEV = 2,
        envTEST = 3,
        envPROD = 4
    }
     private static enumEnvironment GetCurrentEnv()
    {
        if (ConfigurationManager.GetSection("DBSettingsGroup/DBSettings") == null && ConfigurationManager.GetSection("DBSettings") == null)
        {
            return enumEnvironment.envLOC;
        }
        else
        {
            NameValueCollection NVCollection = new NameValueCollection();
            NVCollection = (NameValueCollection)ConfigurationManager.GetSection("DBSettingsGroup/DBSettings");
            if(NVCollection == null)
            {
                NVCollection = (NameValueCollection)ConfigurationManager.GetSection("DBSettings");
            }

            string sEnv = NVCollection.GetValues("serverrole").ToString();

            switch (sEnv.ToUpper())
            {
                case "DEV-ISOLATED":
                    return enumEnvironment.envDEV;
                case "DEVELOPMENT":
                    return enumEnvironment.envDEV;
                case "TEST":
                    return enumEnvironment.envTEST;
                case "PRODUCTION":
                    return enumEnvironment.envPROD;
                default:
                    return enumEnvironment.envNONE;
            }
        }
    }
   public static string GetURIPath()
    {
        switch (GetCurrentEnv())
        {
            case enumEnvironment.envPROD:
                return "http://produrl/yourapp/api/";
            case enumEnvironment.envTEST:
                return "http://testurl/yourapp/api/";
            case enumEnvironment.envDEV:
                return "http://devurl/yourapp/api/";
            default:
                return "http://localhost/yourapp/api/";
        }
    }
}

【讨论】：