IIS支援在一臺伺服器上並存多“站點（Sites）”主機。這些站點由IP地址、主機名稱、和/或埠號組成。例如假設我的站點是http://www.aspcool.com，它的IP地址為192.197.157.24，主機名稱是www.aspcool.com，埠號是80（預設的HTTP埠）。  而Nikhil的站點是http://www.nikhilk.net，它的伺服器和我的在同一臺Web伺服器上，所以和我一樣，它擁有192.197.157.24 IP地址和預設的80埠，但是唯一不同就是繫結的主機名稱不同。只要這三個之中（IP地址、主機名和埠號）有一個不同，就可以區分每一個站點，進而就可以單獨對映到IIS Web伺服器
  
   當一個站點經過註冊和IIS關聯後，你需要建立該站點的主目錄，該主目錄指出了將來您上傳的頁面檔案的存放地址。當安裝IIS時，預設的站點路徑主目錄對映的是c:/inetpub/wwwroot這個目錄，如果你直接放置一個檔案，例如test.html在該目錄下，你就可以使用http://localhost/test.html

    IIS同樣此持虛擬路徑（virtual directories，簡稱vdirs）這一概念，顧名思義，虛擬路徑並不是真實的路徑，它可以把URL對映成邏輯路徑，進而對映到物理離境，這樣可以很好的保護檔案。

     例如，我建立了一個名稱為app1 的虛擬路徑，並且對映到 c:/inetpub/app1，然後在app1目錄下建立了一個名稱為test2.htm的文，並結合IIS預設的設定，那麼具體使用者請求對映如下：
http://localhost/test.html

    注意：上面的wwwroot和app1是平等的，或者說它們在同一資料夾下，所以雖然從URL邏輯上看似乎app1應該在wwwroot目錄下，但是其實您並不能夠確保實際存放是這樣的。

     IIS同樣支援應用程式（Application）這一概念，這一概念和虛擬路徑類似，它們在IIS6版本里還支援管理員來管理堆不同應用程式池的對映。(注意：ASP.NET的應用程式這一概念已經和傳統的ASP應用程式的概念不同，它是應用程式的入口)

   IIS的Application同樣可以對映到主目錄下的物理路徑，它還可以對映到主目錄以外的其他路徑。它們能夠支援多層次的深度巢狀

例如
http://www.testsite.com/ -> c:/www.testsite.com/wwwroot (應用程式的主目錄)

http://www.testsite.com/app1 -> c:/www.testsite.com/app1

http://www.testsite.com/app2 -> c:/www.testsite.com/app2

http://www.testsite.com/app3 -> c:/www.testsite.com/wwwroot/app3

http://www.testsite.com/app3/app4 -> c:/www.testsite.com/wwwroot/app3/app4

注意上面例子裡Application的主目錄(http://www.testsite.com/) ，app1(http://www.testsite.com/app1)以及app2 (http://www.testsite.com/app2) ，從URL路徑上看似乎app1和app2是在主目錄下進行繼承，但是其實在物理路徑上是平等的。

   這裡特別強調一下，當你在IIS裡在右擊滑鼠選擇“建立虛擬路徑”時，你其實同時也建立了一個應用程式（Application），（特別的，此時虛擬路徑已經自動設定了一些應用程式元資料）

   如果你不想要這些應用程式元素，你可以開啟剛建立的虛擬目錄的屬性頁，最主要的記住：IIS實現對虛擬路徑的繫結，而不是對物理路徑的繫結，這一點決定了應用程式的範圍和邊界。

   上面的對映，如果你開啟IIS應該類似如下你可以單擊刪除，這並不會刪除虛擬路徑，但它會刪除應用程式，一般並不建議這麼做。



ASP.NET 2.0和應用程式

  ASP.NET使用IIS應用程式元資料標示（這些標識存放在IIS元資料配置系統裡）來區分每一個應用程式的應用區域，並且關聯到具體主機內容，特別的，一個目錄被對映成ASP.NET虛擬路徑後會做如下一些事情：
（1）它允許在當前應用程式的主目錄下建立一個 /bin 資料夾以此來解決彙編程式集合的引用，並可以立即使用它。
（2）它允許應用程式集等級（application-level）可以設定身份驗證（具體在web.config裡配置）。
（3）它允許全域性設定（global.asax）檔案定義處理全域性等級事件（例如Application_Start/End，以及具體的模組事件如Session_Start/End）
（4）上面這些都在ASP.NET 2.0版本進行了支援，除此以外在ASP.NET2.0版本里，為了部署應用程式的方便和資源共享，它還提供了額外的目錄，你可以在應用程式主目錄下建立這些額外的目錄，這寫額外的目錄包括App_Data、App_Code等以便提供資料訪問、類庫的編譯和應用程式資源等。

何謂IIS的元資料標識？對於熟悉Windows的使用者來說，應該知道windows系統的配置在登錄檔裡，同樣IIS也採用了配置檔案的思想其配置資訊放置在meta資料庫裡，這就是我們通常稱為的元資料庫

ASP.NET會建立一個CLR的應用程式區域來處理正在允許應用程式程式碼的上下文環境。這個應用程式區域時在程式碼載入策略的設定裡（也就是解決應用程式彙編集怎麼掛接到 /bin 目錄下），以前額外的程式碼訪問許可權問題。
使用上面的 www.testsite.com應用程式繫結的例子，這意味這/bin資料夾的位置應該類似如下： c:/www.testsite.com/wwwroot/bin 
c:/www.testsite.com/app1/bin 
c:/www.testsite.com/app2/bin 
c:/www.testsite.com/wwwroot/app3/bin 
c:/www.testsite.com/wwwroot/app3/app4/bin


 /app1執行時的程式碼會使用/app1/bin資料夾的彙編集。
/wwwroot/app3 執行時的程式碼會使用/wwwroot/app3 /bin 檔案下的彙編集
/wwwroot資料夾下的執行時程式碼（注意不是/wwwroot/app3目錄下）將使用/wwwroot/bin資料夾下的程式碼來載入彙編集
注意：這些彙編集是由.NET框架ASP.NET V1,V1.1和V2.0進行區分的


使用Visual Studio.NET 2005

 重要說明：在下面的介紹了，我們使用了Visual Web Express2005來開發ASP.NET2.0。VWE2005是Visual Stduio.NET2005的一部分，雖然VS.NET2005功能很強大，但是根據應用情況（例如有些人用C#版，就不用安裝VB版本）有許多功能其實並不需要，所以這裡說的VS2005其實是VWE2005，您可以到  http://www.asp.net  免費下載
    VS2005支援多種方式來開啟和編輯ASP.NET應用程式。總體概括起來有四種方式：File System、Local IIS、FTP Site和Remote Site。如下圖

本節主要介紹Local IIS，其它方式以後會介紹。

有些人可能會問如果如果使用Local IIS，你開啟一個web站點時，該站點有多個巢狀的子應用程式怎麼辦？例如當你開啟www.testsite.com(應用程式根目錄)，而根目錄下包含多個子應用程式（(www.testsite.com/app1, www.testsite.com/app2, 和 www.testsite.com/app3），一個廣為關注的問題就是VS2005會不會將所有的子目錄整合在一起，因為繫結的應用程式和專案會編譯在/bin目錄下（而事實上/bin目錄和這四個應用程式應該不同）。

一個非常好的訊息是VS2005能夠正確的獲取每一個應用程式界定範圍，也就是說當你開啟一www.testsite.com應用程式的時候，你在VS2005裡開啟的專案看起來類似如下

從解決方案資源管理器裡可以看到，VS2005只包含在www.testsite.com應用程式裡夾，和應用程式的子資料夾（例如上面的subdirectory1和subdirectory2）。 這樣當你使用VS2005進行編譯時，它僅僅編譯包含在www.testsite.com應用程式裡面的檔案（注意這裡不包括子應用程式）。而如果你部署該web專案，你頁將僅僅部署這些在www.testsite.com的主應用程式（不包括子應用程式）。這其實和VS2003是一樣的。

另外VS2005進一步改善了在資源管理器裡巢狀的應用程式的圖示的顯示，（請參考上面的app1，App2和app3的圖示），這些圖示能夠讓開發人員識別這些應用程式在web邏輯空間裡它們是子應用程式，而並不是開發時的具體檔案存放位置。

這些子應用程式並不包含具體的內容（這和VS2003類似），所以你並不能夠展開它們的內容，因為它們的設計目的是讓你知道那裡有這樣一個子應用程式，目的是可以快速幫助你理解整個應用的體現結構。

另外還有一點需要注意，在上面app3種被對映到c:/www.testsite.com/wwwroot/app3物理路徑，它直接是在主目錄 www.testsite.com應用程式（c:/www.testsite.com/wwwroot/）下，可是它被標記為應用程式，所以當你編譯www.testsite.com專案時，他會排斥編譯app3應用程式到主應用程式裡，而subdirectory1和subdirectory2併為標記為應用程式，它將作為主目錄的一部分編譯到主應用程式裡。

另外一個工作流程改進點是VS2005允許你通過雙擊子應用程式圖示來新增專案。當你在子應用程式上雙擊（例如在app3上雙擊）將彈出開啟web站點對話方塊，如圖，他會問你時開啟該app3應用程式（這將關閉當前www.testsite.com應用程式）還是將該app1應用程式新增到當前www.testsite.com應用程式。

 例如我選擇“add the web site to the current solution”,然後單擊OK，這樣你的解決方法資源管理器將被分為兩個專案，看起來如下

例如 我選擇“add the web site to the current solution”，這樣當我在解決方案資源管理器單擊app3圖示時，它就出現如下

你可以象使用VS2003的同樣方式那樣來使用VS2005管理Web應用程式以及子應用程式。比較典型的的子應用程式巢狀的例子是包含一個Web專案和一個或者多個類庫。

在下面的這個示意圖是一個包含了三層體現結構的應用程式：一個web專案、一個或者多個類庫等。我在這個解決方案裡增加了資料訪問層（Data Access Layer，DAL）和業務邏輯層（Business Logic Layer，BLL）。

接下來，你就可以設定專案之間的引用和編譯的依賴管理，例如上面的這個例子依賴關係如下：

  這樣BLL層建立在DAL的基礎上，而http://localhost:81/則建立在BLL基礎上，這種依賴關係決定了系統編譯的順序為：先編譯DAL、然後編譯BLL最後編譯http://localhost:81 這個Web專案。

我接下來就可以直接保儲存我的解決方案，這個解決方法封裝了所有的專案（包括專案之間的相互引用和依賴關係），在這方面它和和VS2003是類似的，以後我只要開啟該解決方案，系統將子定載入所有的專案和資源、檔案。

當以後我發以後釋出Web站點時，它會將DAL、BLL和Web專案的整體結果整合在一起編譯成二進位制檔案，因此當我釋出web網站時，你並不需要DAL和BLL專案。

（關於上面DAL、BLL等具體的實際應用您可以參考《ASP.NET技術詳解與應用例項》的最後一章） 

使用ASP.NET2.0版本

最後在說一下ASP.NET的版本問題。正如Visual Stuido.NET2003和.NET Framework V1.1配合的很好一樣，Visual Studio.NET 2005和.NET Framework V2.0同樣協調的也很好。這意味這VS2003和VS2005可以裝在同一臺機器上。原有的專案您仍然可以使用VS2003繼續開發，而新的專案你可以選擇使用VS2005進行開發。

這也意味這你可以選擇你的ASP.NET應用程式在web伺服器上的執行版本，您可以讓有些應用程式執行在ASP.NET1.1版本上，有些執行在ASP.NET2.0版本。也就是說，你可以自行決定.NET執行版本的控制。

預設的如果你以前在你的機器上安裝了ASP.NET1.1版本，然後又安裝ASP.NET2.0後，一般你也不會考慮立刻更改應用程式並升級到最新的版本，相反你可能想自行決定應用程式的使用的版本，正式由於這個原因，因此當你安裝ASP.NET2.0時，系統並不會更改您的預設設定，而仍然使用ASP.NET1.1版本。

為了實現.NET版本控制的功能，系統是通過使用IIS新增加的“ASP.NET”頁標籤來實現的，ASP.NET頁標籤是在我們安裝.NET2.0版本時自動新增的。在根目錄的屬性力，可以設定預設全域性應用程式版本如下圖，除此以外該頁標籤自動新增在任意一個應用程式的屬性裡，這頁允許我們可以單獨設定每一個應用程式的使用版本。

這裡需要強調一下“級聯”性質，以前敘為例子，如果我將app2設定為使用.NET 2.0，那麼此時app3如果是.NET1.1版本，則保持不變，因為app2和app3是並列的；

然而如果我將app3設定為.NET2.0，由於app4預設叢屬於app3，所以如果原先app4是.NET1.1版本，則會更新為.NET2.0版本。