本章我們將講解ASP.NET5項目發布部署相關的內容，示例項目以我們前一章創建的BookStore項目為例。

發布前的設置

由于新版ASP.NET5支持多版本DNX運行環境的發布和部署，所以在部署之前，我們需要設定部署的目標DNX（即之前的KRE）。

步驟：右鍵BookStore項目->屬性->Application選項卡，選擇DNX的版本，本例中，選擇dnx-coreclr-win-x64.1.0.0-beta4。

在project.json文件的commands節點，我們可以看到，系統默認配置了3個調試命令，分別如下：

理論上來說，我們F5運行的時候，應該是啟動web命令，但是在VS2015中，默認的運行環境依然是IIS Express，所以F5調試的時候，會默認啟動IIS Express。

注意：web模式和IIS Express模式的程序運行端口不一樣。

我們先F5調試運行，啟動IIS Express，打開頁面，一切正常。重新選擇默認模擬器環境為web，再F5運行，這時候發現彈出了一個命令行窗口，并提示如下文字：

[INFORMATION:Microsoft.NET.Http.Server.WebListener] Start[INFORMATION:Microsoft.NET.Http.Server.WebListener] Listening on prefix: http://localhost:5000/Started

代碼沒有出錯，但是并沒有打開瀏覽器窗口，我們手工打開一個瀏覽器訪問上述網址，即可看到該示例程序的界面，此時說明，該BookStore已經成功運行在5000端口了。其實該模式下的瀏覽器自動打開功能默認是關閉的，可以通過如下方式開啟自動打開功能：

步驟：右鍵BookStore項目->屬性->Debug選項卡，勾選Launch Brower復選框，并在輸入框里輸入上述網址即可（此時會在項目的Properties目錄下生成一個debugSettings.json文件來保存上述信息）。

再次F5運行，即可看到自動打開的瀏覽器界面。

應用程序參數
在該Debug選項卡中，我們還看到一個應用程序參數（Application Arguments）輸入框，該輸入框可以傳入多種參數，這些參數可以在Startup.cs里，通過Configuration的AddCommandLine方法進行收集并利用。

環境變量
同理，在Debug選項卡的最下面還有一個環境變量（Environment Variables）輸入框，可以讓我們在調試的時候自定義一些環境變量的值（key/value），然后通過Configuration的AddEnvironmentVariables方法進行收集并利用。

上述參數和環境變量的具體使用方式，請參考配置信息管理章節。

發布流程分析

在之前的MVC程序中，我們一般都是通過右鍵項目，選擇發布（Publish）的方式來發布程序的，這一次我們也來看看這種方式。

首先，右鍵->發布->Profile（選擇File System）->選擇D:/BookStore->選擇Release/coreclr->下一步，最終點擊發布。在在Output面板，我們看到出錯了，錯誤信息如下：

正在連接到 D:/Documents/Visual Studio 2015/Projects/BookStore/BookStore/../artifacts/bin/BookStore/Release/Publish...C:/Program Files (x86)/MSBuild/Microsoft/VisualStudio/v14.0/Web/Microsoft.DNX.Publishing.targets(342,5): 錯誤 : 錯誤: 無法識別規則“BackupRule”。C:/Program Files (x86)/MSBuild/Microsoft/VisualStudio/v14.0/Web/Microsoft.DNX.Publishing.targets(342,5): 錯誤 : 錯誤計數: 1。C:/Program Files (x86)/MSBuild/Microsoft/VisualStudio/v14.0/Web/Microsoft.DNX.Publishing.targets(342,5): 錯誤 : An error occured during publish.The command ["C:/Program Files (x86)/IIS/Microsoft Web Deploy/msdeploy.exe" -source:contentPath='C:/Users/Administrator/AppData/Local/Temp/PublishTemp/' -dest:contentPath='D:/Documents/Visual Studio 2015/Projects/BookStore/artifacts/bin/BookStore/Release/Publish' -verb:sync -enableRule:DoNotDeleteRule -retryAttempts:2 -disablerule:BackupRule ] exited with code [-1]。

通過查看輸出信息，可以發現，編譯成功，但復制的時候出錯，可能是powershell的問題，所以返回上述步驟，在設置（Settings）選項卡下，將取消發布腳本（Publish Scripts）下的使用PowerShell腳本發布的復選框。重新發布，成功了。

打開發布目錄D:/BookStore，發現生成了如下目錄和文件：

看到cmd文件的擴展名，我們可以猜想這些命令是用于執行相關的命令，比如web.cmd可能就是用于啟動程序的；而非cmd擴展名文件，我們則猜想可能是用于linux/mac運行的命令。

我們來試一下，點擊web.cmd文件，該文件執行以后顯示的信息和我們在Debug程序時彈出的信息一樣，通過訪問提示中的網址，我們可以驗證應用程序已經正常運行了。這種模式即時我們所說的自宿主（Self-Host）運行模式。

再試一下IIS是否能夠運行該程序，將IIS站點指向到wwwroot目錄，打開網址，也是可以正常訪問的。打開wwwroot文件夾進行查看，靜態文件一應俱全，但是發現bin目錄下并沒有我們的項目DLL（BookStore.dll），而是多了一個AspNet.Loader.dll，而且根目錄下還多了一個web.config文件，內容如下:

<?xml version="1.0" encoding="utf-8"?><configuration> <appSettings> <add key="bootstrapper-version" value="1.0.0-beta4" /> <add key="runtime-path" value="../approot/packages" /> <add key="dnx-version" value="1.0.0-beta4" /> <add key="dnx-clr" value="coreclr" /> <add key="dnx-app-base" value="../approot/src/BookStore" /> </appSettings></configuration>

通過查詢相關信息（訪問詳情） ，得知AspNet.Loader.dll文件只是一個橋接文件，用于接收IIS轉發過來的請求，然后將其轉交給dnx進行運行，這里的web.config里的dnx以及項目信息的配置文件是AspNet.Loader.dll在轉交請求時所需要的配置信息。

通過配置文件我們可以看到，這里配置了dnx的類型、版本號，程序集的路徑和app的路徑。打開approot/src/BookStore目錄，我們發現，這里居然都是cs源碼，雖然有個bin目錄，但是里面也沒有dll文件。而且在approot/packages文件夾下，居然有90個程序集文件夾（將近30M文件）。

通過查詢網站的資料得知（這一部分內容，我們在下一節進行講解），目前真正運行程序的運行環境是DNX，也被復制到approot/packages/dnx-coreclr-win-x64.1.0.0-beta4目錄中， 而該項目依賴的所有程序集（包括System開頭的）都被復制到該packages目錄下了。目的就是要做到真正的跨平臺運行，也就是說，將這些文件復制到linux系統下，只要有對應版本的KRE（本例中的DNX是Windows版本的）的話，就可以正常運行該程序。

而bin目錄下沒有dll文件，則是使用了微軟最新的動態編譯技術，即在運行的過程中，自動編譯cs文件，而且一旦修改這些cs文件的話，系統將會自動再次進行編譯。（感覺有點像php等腳本語言了）。雖然動態編譯很高效，但是還是沒有編譯好的dll高效，所以微軟還提供了一個選項讓開發人員在調試的時候生成dll文件。具體步驟如下：

右鍵BookStore->屬性->Build選項卡，勾選編譯時生成輸出（Produce outputs on build）復選框。

重新編譯程序，發現在BookStore/artifacts/bin/BookStore/Debug目錄下的2個DNX版本文件夾下都分別生成了BookStore.dll文件了，而且還順帶了Nuget的spec文件。

如果在發布的時候也要生成dll文件，則需要在發布（Publish）設置里進行修改，步驟如下：

右鍵BookStore->發布（Publish）->Settings選項卡->File Publish Options->勾選Precompile during publishing復選框。

這樣就可以生成響應的dll文件， 但是這些dll文件依然不在wwwroot/bin目錄下，而是在approot/packages/BookStore/1.0.0目錄下，在該目錄下有2個文件夾，分別是lib和root，以及相關的Nuget的spec文件，在lib目錄下，生成的是不同dnx版本的dll文件，而root則是類似于之前的web根目錄，因為在該目錄下除了有視圖文件以外，還和以前的結構一樣，保留了bin目錄，并且在bin目錄下的Release文件夾下，也有一份針對不同dnx版本的dll文件副本。

提示：上述選擇中，另外一個Delete all existing files prior to publish也可以勾選上，以便在發布時將之前發布版本的所有文件全部清空。

此時，我們通過web.cmd文件或者IIS模式來驗證發布的文件，經驗證，均可以正常運行。再仔細對比兩份不同設在的發布文件，發現，除了dll文件以外，web.config文件的應用程序路徑也變了，即從原來的：

<add key="kre-app-base" value="../approot/src/BookStore" />

變成了如下版本：

<add key="kre-app-base" value="../approot/packages/BookStore/1.0.0/root" />

而web.cmd文件的內容，也從如下內容：

@"%~dp0approot/packages/dnx-coreclr-win-x64.1.0.0-beta4/bin/dnx.exe" --appbase "%~dp0approot/src/BookStore" Microsoft.Framework.ApplicationHost web %*

變成了如下內容：

@"%~dp0approot/packages/kre-coreclr-win-x64.1.0.0-beta4/bin/dnx.exe" --appbase "%~dp0approot/packages/BookStore/1.0.0/root" Microsoft.Framework.ApplicationHost web %*

上述變化，我們是可以理解的，即將src源碼動態編譯運行的模式修改為預編譯dll程序集的模式。所以，在這里我們可以看到，在源碼動態編譯模式下，其發布后的文件夾結構如下：

//源碼動態編譯模式wwwroot/bin/Microsoft.AspNet.Loader.IIS.dllwwwroot/Contents/site.csswwwroot/Contents/...............................................................................................wwwroot/Scripts/jquery.jswwwroot/Scripts/........................................................................................................................................................approot/src/BootStore/project.jsonapproot/src/BootStore/...............................approot/src/BootStore.Data/project.jsonapproot/src/BootStore.Data/..............................approot/src/BootStore.Bussiness/project.jsonapproot/src/BootStore.Bussiness/.........................approot/packages/Elmah/{version}/...............................................................................

而dll預編譯模式下的發布文件夾結構如下：

//dll預編譯模式wwwroot/bin/Microsoft.AspNet.Loader.IIS.dllwwwroot/Contents/site.csswwwroot/Contents/...............................................................................................wwwroot/Scripts/jquery.jswwwroot/Scripts/........................................................................................................................................................approot/packages/BootStore/{version}/...................approot/packages/BootStore.Data/{version}/..............approot/packages/BootStore.Bussiness/{version}/.........approot/packages/Elmah/{version}/.......................

IIS和web.cmd模式的不同

雖然我們對dnx內容的原理不太理解，但有一點內容，我們要記住，那就是兩種模式下，對靜態文件的訪問模式可能不太一樣。原因是因為，雖然IIS模式的根目錄就是存放靜態文件的地方，但是web.cmd文件事先啟動的卻是approot/src/BookStore目錄或approot/packages/BookStore/1.0.0/root目錄，兩個目錄下均沒有靜態文件，因為靜態文件時在wwwroot目錄下的，我們猜想，在這種模式下，肯定會有一種機制在來映射這些靜態文件，通過查找文件發現，在approot/src/BookStore目錄下的project.json文件中的webroot鍵的值，從解決方案中默認的wwwroot變成了"../../../wwwroot"，也就是說kre在映射靜態文件的時候，應該是根據這個相對目錄來查找這些文件的。

同理，approot/packages/BookStore/1.0.0/root目錄下的project.json文件中的webroot鍵的值，也從wwwroot變成了"../../../../../wwwroot"（因為本來project.json文件的層級就深）。

由于IIS是通過AspNet.Loader.dll做中轉，將請求轉交給DNX來運行的，那么在IIS模式下，靜態文件的請求到底是IIS來處理，還是KRE來處理呢？我們來驗證一下，驗證步驟如下：

創建一個wwwroot2文件夾和wwwroot同級，并將wwwrooot目錄下的靜態文件剪切到wwwroot2目錄下。將project.json（如果是預編譯模式，則需要修改root目錄下的project.json）文件中的webroot值中的wwwroot修改為wwwroot2。繼續以IIS模式運行該站點

結果發現，靜態文件訪問不了了（CSS、JS、Images均失效了），但我們再通過web.cmd運行時，這些靜態文件卻又可以訪問了。由此得知，在IIS模式下，靜態文件走的是IIS的管線Pipeline，而不是DNX的關系Pipeline。

兩種發布模式下的project.json文件不同

動態編譯模式和預編譯dll模式這兩種模式的自動發布程序，生成后的project.json文件有一些變化，具體變化如下。

動態編譯模式
基本上和解決方案里的project.json文件相同，唯一的不同就是webroot的相對路徑的修改。

預編譯dll模式
原來引用的眾多程序集從dependencies節點中移除了，取而代之的是BookStore程序集引用，示例如下：

"dependencies": { "BookStore": "1.0.0"},

另外，還多了如下兩個節點值（具體功能暫不明確）：

"entryPoint": "BookStore","loadable": false

猜想，這些不同，可能是因為在動態編譯模式下需要引用這些被移除的程序集進行編譯，而預編譯dll模式下，都已經編譯好了，所以就不再需要這些程序集了，而root目錄只需要引用BookStore程序集就可以了，而BookStore程序集對這些程序集的依賴，詳細在該dll程序集的nupkg文件里是可以自動解析并下載的吧（這一點待驗證）。

以上是新版ASP.NET5項目在發布流程和相關技術的一些內容，從這里大家可以看到，ASP.NET5是徹底模塊化了，IIS不再是運行MVC程序的唯一容器，任何兼容DNX的運行容器都可以運行MVC程序，程序發布包被分為approot和wwwroot兩個部分，分別存放應用程序集（或源碼）和靜態文件，從而做到更好的分離。在下一章，我們會討論，ASP.NET 5的運行原理。

注意：目前還沒有辦法通過復制源碼的形式來進行調試，同時也沒辦法將IIS指向到源碼中進行調試，這將會改變開發人員的開發習慣。