为不同环境拆分 web.config

• 下载完整源代码 - 172.57 KB

引言

为不同环境拆分 web.config 文件是一个绝妙的想法，因为它在减少工作量、避免不同环境之间文件的混淆、降低文件错乱的几率以及安全地存放凭据等方面都有许多优势。微软提供了实现这一点的功能，我认为大多数人在设置不同环境时都没有充分利用这一便利。

智能拆分 web.config 的优势

两种不同环境的文件结构

生产

UAT 和 Staging

一个案例研究

这是一个旧的环境

1. 我们有很多国家/地区的网站，它们拥有相同的源代码但独立的域名（出于一些合理的原因）和独立的部署。
2. 我们有开发、测试和预生产（staging）环境。
3. 我们进行错误修复、性能优化和新功能增强。
4. 团队中有一些承包商，他们几乎知道所有的凭据。
5. 我们有专门的部署团队负责测试和预生产环境。
6. 我们需要提交工单来更正部署中的条目或任何内容。

在我们想到拆分 web.config 之前，我们是这样做的：

1. 我们使用 NAnt 脚本将二进制文件复制到所有国家/地区的网站。
2. 有一些共享密钥需要分发到所有网站，我们通过打开每个国家/地区的网站手动更新（有时，我们可以使用 NAnt 脚本完成，但并非总是如此）。
3. 我们不太关心数据库密码和其他凭据。
4. 有时我们会弄混不同环境的配置文件，然后提交另一个工单来更改它，并等待处理。

这是真正的优势

1. 我们将所有通用密钥（appSettings）存储在一个通用配置文件中，供所有国家/地区的网站共享。
2. 所有凭据（如密码）都被移至另一个文件，该文件只能由系统管理员访问。
3. 我们为不同环境维护独立的特定文件，因此完全没有混淆。
4. 一些特定于网站的 appSettings，我们将其存储在网站级别，而通用的 appSettings 密钥则存储在共享密钥文件中。

您的场景可能还有其他优势。

源代码示例

将密钥 <appSettings> 拆分到两个不同的文件中。

Web.config

<configuration>
  <connectionStrings configSource="admin.config" />

  <system.web>
    <compilation debug="true" targetFramework="4.0" />
  </system.web>
  
<appSettings file="key.config" >
    <add key="ChildKey1" value="ChildValue1"/>
    <add key="Childkey2" value="ChildValue2"/>
  </appSettings>

  <system.webServer>
    <modules runAllManagedModulesForAllRequests="true"/>
  </system.webServer>
</configuration>

Admin.config

<connectionStrings >
  <add name="BannerConnectionString" 
connectionString="Data Source=localhost;Initial Catalog=Banner;Integrated Security=True"
providerName="System.Data.SqlClient" />
</connectionStrings>

Key.config

<?xml version="1.0" encoding="utf-8"?>
<appSettings >
  <add key="ChildKey1" value="ChildValue1"/>
  <add key="ChildKey2" value="ChildValue2"/>
</appSettings>

最后，非常重要的一点

如何保护拆分的配置文件不被最终用户访问

拆分的文件必须对最终用户隐藏，这一点非常重要，可以通过以下两种方法实现：

1. 管理员可以通过将新的配置文件保存在单独的文件夹中来限制文件夹级别的访问。
2. 我们可以使用 web.config 中 ASP.NET 内置的访问系统来限制文件。

   <location path="Key.Config">
     <system.web>
       <authorization>
         <deny users="*"/>
       </authorization>
     </system.web>
   </location>

如果您的环境是以下任何一种，拆分 web.config 的优势不大：

1. 小型应用程序，只有少数开发人员，并且除了开发和生产环境之外没有其他环境。
2. 您的应用程序不太关心其使用的数据库的安全性。
3. 您没有单独的管理或部署团队来执行生产或 UAT 部署。
4. 出于某种原因，不同环境中的配置文件始终保持同步。

大多数人会因为以下原因而忽略这一点：

1. 部署发生的频率非常低，而且这是一次性工作。
2. 人们除非数据库被未经授权的人访问，否则不会太在意安全问题。
3. 即使不同环境中的配置文件被弄乱了，也可以通过少量工作进行更改。

结论

这是一个简单的想法，但我认为将其公开是有益的，如果您有更好的想法或任何评论，请告诉我。

祝您阅读愉快！

历史

• 2011 年 2 月 21 日：初始帖子