ASP.NET MVC 從零開始 - Web.config - lxconan－IT工程師數位筆記本

文章出處

這篇文章是從我的 github 博客 http://lxconan.github.io 導入的。

在上一篇中，我們從零開始創建了一個非常簡單的 ASP.NET MVC 應用程序。接下來，你是不是期望我們能夠給這個新生的應用程序添加各種各樣的功能呢？可惜，不是這樣的。我們下面的工作是創造一個自動部署這個應用程序的腳本。這在任何時候都是非常重要的。

這個重要的任務很難在一篇文章中完成，因此我們先看一看自動部署中一個非常重要的部分：web.config 文件。在這篇文章中，我們將解決如下的問題：

web.config 文件是個什么東西
web.config 對部署的影響

web.config 文件是什么

一般來說，web.config 文件包含了所有運行 ASP.NET 應用程序所需的配置信息。你也許馬上發現了破綻：真的是“所有”嗎？在上一個應用程序中它一共只有不到10行代碼：

<?xml version="1.0"?>

<configuration>
  <system.web>
    <compilation debug="true" targetFramework="4.5" />
    <httpRuntime targetFramework="4.5" />
  </system.web>
</configuration>

但是這個應用卻可以依靠著這個配置文件運行在 IIS Express 中，當然，也會運行在 IIS 中。

如果只算這個 web.config 文件，當然沒有包含所有的配置。為了運行我們的 Web 應用，至少要包含三個方面的信息：

我們的 Web 應用也是一個 .NET 應用，因此會包含一些 .NET 應用通用配置信息。例如 <connectionString>、<system.data> 配置節的內容就是此類配置的典型；
其次我們的 Web 應用是一個 ASP.NET Web 應用程序，因此會包含 ASP.NET 相關的配置信息。例如 <system.Web> 配置節的內容就是此類配置的典型；
到目前為止，我們的 Web 應用是 Host 在 IIS 上的，因此需要包含 IIS 相關的配置信息。例如 <system.webServer>、<system.applicationHost>、<system.ftpServer> 配置節就是此類配置的典型；

那么這么多的信息是如何組織起來的呢？實際上這些信息是通過一種繼承的方式進行組合的。以我們所做的 Web 應用為例。當應用分別部署在 IIS 和 IIS Express 上的時候，會有如下的配置繼承結構：

IIS 7:
{.NET Framework Dir}\Config\machine.config
{.NET Framework Dir}\Config\web.config
{IIS Dir}\Config\applicationHost.config
    |-{Our Web Application Dir}\web.config

IIS Express
{.NET Framework Dir}\Config\machine.config
{.NET Framework Dir}\Config\web.config
{IIS Express Dir}\config\AppServer\applicationHost.config
    |-{Our Web Application Dir}\web.config

繼承結構的第一級是服務器范圍內的根配置文件，這種配置文件有三個：

首先出現的是 machine.config 和根 web.config。其中前者的配置將應用于本機的所有 .NET 應用，而后者的配置將應用于所有的 ASP.NET 應用。這兩個文件的路徑都位于 .NET Framework 的特定版本所在的目錄。例如，例如 .NET 2.0 的安裝路徑是 %windir%\Microsoft.NET\Framework\v2.0.50727, .NET 4.0 的安裝路徑是 %windir%\Microsoft.NET\Framework\v4.0.30319（64-bit 的 .NET Framework 的 Framework 文件夾的名字是 Framework64）。
服務器范圍內的配置文件還有 applicationHost.config。這個配置文件是用于存儲 IIS 的運行配置的，它的值將作用于所有部署于本機 IIS / IIS Express 的應用。

繼承結構的第二級就是我們的 Web 應用，這種應用可以存在于 Web 應用的根路徑和各級虛擬目錄。他們的繼承層次和虛擬目錄的層次是一致的。

web.config 和部署

繼承機制是非常不錯的，但是這引入了另外一個問題，如果目標服務器并沒有這些默認配置，或者這些配置在不同環境不盡相同，那么我們的應用程序不就不能正常工作了嗎？很不幸，被你言中了。這就是為什么當你先安裝了 .NET Framework 而后安裝了 IIS 服務的話需要執行 aspnet_regiis 的原因了。不過我們還是有幾種方法來應對這個問題：

把所有的配置覆寫一遍（找抽），這里所謂的覆寫僅限于 .NET 應用配置和 ASP.NET 應用配置，IIS 的 applicationHost.config 不要手動更改可以通過 .NET IIS Interop 或者 powershell 的 IIS Extension 進行更改。
重寫當前應用程序使用到的的配置節（即使它已經存在在開發環境下的 machine.config 和根 web.config 中）；
重置當前服務器的默認配置文件(machine.config 以及 web.config)，然后以此為基礎，僅僅書寫和默認配置不同的配置。

上述三種方法中，后兩種方法是比較可行的。但是在閱讀了下一篇，也就是關于 ASP.NET 處理機制的介紹之后，你會發現第二種方法仍然存在相當的難度（因為需要覆寫的東西實在太多）。因此目前廣泛采用的是第三種方法。

以上就是這一篇的內容，現在還不是我們寫部署腳本的時候 :-)。下一篇我們將介紹 ASP.NET 的處理機制。

附1：machine.config 的默認設定

默認使用 RSA 對受保護的 config 文件進行加密；
默認連接本地 aspnetdb.mdf 數據庫；
默認激活如下的 WCF Service Behavior：
- Windows Workflow Foundation 相關 Service Behavior；
- WS*-HTTP，以及 RESTful WCF Service Behavior（和 .NET 3.5SP1 兼容，但是之后應該使用 WebApi）；
- WCF Service Discovery Behavior；
- WCF 服務 Buffer 傳輸支持（相對的還有 Stream 傳輸支持）；
WCF 的 WS*-HTTP，TCP，web-HTTP，basic-HTTP 綁定支持；
WCF 的各種 endpoint 支持；
默認使用 SQL Server 進行 Membership 和 Role 的管理（Authentication 相關）；
默認使用 SQL Server 存儲 Profile 的結果；

附2：根 web.config 的默認設定

指定了不同的 trust level 所對應的根 web.config 文件；
默認的 trust level 是 Full；
將 C# 和 VB 的編譯器添加到服務端頁面編譯器中；
添加服務端頁面編譯時默認引用的程序集，添加需要編譯的文件類型及其相應的 Build Provider；
使用 Internet Settings 中的代理服務器策略；
允許所有用戶訪問 Web 應用程序；
添加 Log 相關的默認緩存設置（包括大小，Flush 間隔等），將系統日志 Logger 設置為默認的 Log Provider，并將不同類型的日志映射到系統日志的類型；
添加默認的 HTTP Handlers（這可能使咱們最常接觸的內容了）；
添加默認的 HTTP Modules；
添加 Web UI 控件支持和站點地圖支持（ASP.NET Webform）；
啟用 Url 映射支持（就是把 Request 的 URI 映射到另外一個 URI）
默認 WCF 的 tcp，MS消息隊列，命名管道并不和 ASP.NET 處理管道相互兼容（他們是分開運行的）；