ASP.NET MVC 從零開始 - Web.config
這篇文章是從我的 github 博客 http://lxconan.github.io 導入的。
在上一篇中,我們從零開始創(chuàng)建了一個非常簡單的 ASP.NET MVC 應用程序。接下來,你是不是期望我們能夠給這個新生的應用程序添加各種各樣的功能呢?可惜,不是這樣的。我們下面的工作是創(chuàng)造一個自動部署這個應用程序的腳本。這在任何時候都是非常重要的。
這個重要的任務很難在一篇文章中完成,因此我們先看一看自動部署中一個非常重要的部分:web.config 文件。在這篇文章中,我們將解決如下的問題:
- web.config 文件是個什么東西
- web.config 對部署的影響
web.config 文件是什么
一般來說,web.config 文件包含了所有運行 ASP.NET 應用程序所需的配置信息。你也許馬上發(fā)現(xiàn)了破綻:真的是“所有”嗎?在上一個應用程序中它一共只有不到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>配置節(jié)的內(nèi)容就是此類配置的典型; - 其次我們的 Web 應用是一個 ASP.NET Web 應用程序,因此會包含 ASP.NET 相關(guān)的配置信息。例如
<system.Web>配置節(jié)的內(nèi)容就是此類配置的典型; - 到目前為止,我們的 Web 應用是 Host 在 IIS 上的,因此需要包含 IIS 相關(guān)的配置信息。例如
<system.webServer>、<system.applicationHost>、<system.ftpServer>配置節(jié)就是此類配置的典型;
那么這么多的信息是如何組織起來的呢?實際上這些信息是通過一種繼承的方式進行組合的。以我們所做的 Web 應用為例。當應用分別部署在 IIS 和 IIS Express 上的時候,會有如下的配置繼承結(jié)構(gòu):
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
繼承結(jié)構(gòu)的第一級是服務器范圍內(nèi)的根配置文件,這種配置文件有三個:
- 首先出現(xiàn)的是
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)。 - 服務器范圍內(nèi)的配置文件還有
applicationHost.config。這個配置文件是用于存儲 IIS 的運行配置的,它的值將作用于所有部署于本機 IIS / IIS Express 的應用。
繼承結(jié)構(gòu)的第二級就是我們的 Web 應用,這種應用可以存在于 Web 應用的根路徑和各級虛擬目錄。他們的繼承層次和虛擬目錄的層次是一致的。
web.config 和部署
繼承機制是非常不錯的,但是這引入了另外一個問題,如果目標服務器并沒有這些默認配置,或者這些配置在不同環(huán)境不盡相同,那么我們的應用程序不就不能正常工作了嗎?很不幸,被你言中了。這就是為什么當你先安裝了 .NET Framework 而后安裝了 IIS 服務的話需要執(zhí)行 aspnet_regiis 的原因了。不過我們還是有幾種方法來應對這個問題:
- 把所有的配置覆寫一遍(找抽),這里所謂的覆寫僅限于 .NET 應用配置和 ASP.NET 應用配置,IIS 的
applicationHost.config不要手動更改可以通過 .NET IIS Interop 或者 powershell 的 IIS Extension 進行更改。 - 重寫當前應用程序使用到的的配置節(jié)(即使它已經(jīng)存在在開發(fā)環(huán)境下的
machine.config和根web.config中); - 重置當前服務器的默認配置文件(
machine.config以及web.config),然后以此為基礎,僅僅書寫和默認配置不同的配置。
上述三種方法中,后兩種方法是比較可行的。但是在閱讀了下一篇,也就是關(guān)于 ASP.NET 處理機制的介紹之后,你會發(fā)現(xiàn)第二種方法仍然存在相當?shù)碾y度(因為需要覆寫的東西實在太多)。因此目前廣泛采用的是第三種方法。
以上就是這一篇的內(nèi)容,現(xiàn)在還不是我們寫部署腳本的時候 ??。下一篇我們將介紹 ASP.NET 的處理機制。
附1:machine.config 的默認設定
- 默認使用 RSA 對受保護的 config 文件進行加密;
- 默認連接本地 aspnetdb.mdf 數(shù)據(jù)庫;
- 默認激活如下的 WCF Service Behavior:
- Windows Workflow Foundation 相關(guān) 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 相關(guān));
- 默認使用 SQL Server 存儲 Profile 的結(jié)果;
附2:根 web.config 的默認設定
- 指定了不同的 trust level 所對應的根 web.config 文件;
- 默認的 trust level 是
Full; - 將 C# 和 VB 的編譯器添加到服務端頁面編譯器中;
- 添加服務端頁面編譯時默認引用的程序集,添加需要編譯的文件類型及其相應的 Build Provider;
- 使用 Internet Settings 中的代理服務器策略;
- 允許所有用戶訪問 Web 應用程序;
- 添加 Log 相關(guān)的默認緩存設置(包括大小,F(xiàn)lush 間隔等),將系統(tǒng)日志 Logger 設置為默認的 Log Provider,并將不同類型的日志映射到系統(tǒng)日志的類型;
- 添加默認的 HTTP Handlers(這可能使咱們最常接觸的內(nèi)容了);
- 添加默認的 HTTP Modules;
- 添加 Web UI 控件支持和站點地圖支持(ASP.NET Webform);
- 啟用 Url 映射支持(就是把 Request 的 URI 映射到另外一個 URI)
- 默認 WCF 的 tcp,MS消息隊列,命名管道并不和 ASP.NET 處理管道相互兼容(他們是分開運行的);
浙公網(wǎng)安備 33010602011771號