一、預編譯的優點 1. 由於頁和代碼文件在第一次被請求時無需編譯，因此可以縮短對用戶的響應時間。這對於更新頻繁的大型網站尤為有用 2. 可以在用戶看到網站之前識別編譯時的 Bug 3. 可以創建站點的已編譯版本，並將該版本部署到成品伺服器，而無需使用源代碼 二、就地預編譯與針對部署的預編譯 1. 就 ...
一、預編譯的優點
1. 由於頁和代碼文件在第一次被請求時無需編譯，因此可以縮短對用戶的響應時間。這對於更新頻繁的大型網站尤為有用
2. 可以在用戶看到網站之前識別編譯時的 Bug
3. 可以創建站點的已編譯版本，並將該版本部署到成品伺服器，而無需使用源代碼
二、就地預編譯與針對部署的預編譯
1. 就地預編譯
就地預編譯網站可以有效執行用戶在請求網頁時所發生的編譯過程。因此，主要的性能改進在於在第一次請求頁時無需對該頁進行編譯。
編譯後的文件存放在%SystemRoot%\Microsoft.NET\Framework\版本\Temporary ASP.NET Files 文件夾下的特殊文件夾中，隨後ASP.NET將通過此文件夾中的程式集來完成頁請求。
如果再次預編譯站點，那麼也只編譯新文件或更改過的文件（或那些與新文件或更改過的文件具有依賴關係的文件）。
2. 針對部署的預編譯
針對部署預編譯，編譯器將基於正常情況下在運行時編譯的幾乎所有ASP.NET源文件來生成程式集。編譯器將從輸出中一處所有的源代碼和標記。編譯後的文件擴展名為.compiled。
若要更改網站頁面的內容，必須更新原始文件、重新編譯網站並重新部署。唯一的例外是網站配置文件web.config。
三、下圖是Visual Studio 針對部署預編譯的配置項
四、高級預編譯設置分析
1. 預編譯選項>>允許更新預編譯站點（不勾選），合併選項>>不合併（勾選）的場景
從圖中可以看到，編譯後的文件直接出現在bin目錄下了，如果你嘗試打開Views文件夾下的視圖文件，會看到“這是預編譯工具生成的標記文件，不應刪除!”的提示信息，也表明瞭，這種預編譯方案會導致每次修改視圖文件都要重新預編譯源文件再發佈。
2. 預編譯選項>>允許更新預編譯站點（不勾選），合併選項>>不合併.為每個頁面和空間創建單獨的程式集（勾選）的場景
和1場景的差異在於dll文件保留了視圖文件名的信息，會比較直觀點。
3. 預編譯選項>>允許更新預編譯站點（不勾選），合併選項>>將所有輸出合併到單個程式集,取名為SingleAssmy（勾選）的場景
可以看到所有的dll，都合併到SingleAssmy.dll中了，反編譯下看看代碼，如圖：
此程式集確實包含了所有程式集信息。
4.預編譯選項>>允許更新預編譯站點（不勾選）
合併選項：將各個文件夾輸出合併到其自己的程式集
合併選項：將所有頁和控制項輸出合併到單個程式集
此兩項配置沒看出有啥區別……
五、個人總結
若要採用部署預編譯，我比較建議使用方案2（預編譯選項>>允許更新預編譯站點（不勾選），合併選項>>不合併.為每個頁面和空間創建單獨的程式集（勾選）的場景）
測試了下，每次發佈後頁面啟動速度非常快，而且方案2可以很清晰的看到預編譯的dll的文件名，方便單個更新。
缺點是：每此視圖文件的編輯，都需要部署預編譯後發佈。
使用命令行部署預編譯
cd C:\Windows\Microsoft.NET\Framework64\v4.0.30319
aspnet_compiler -f -p "D:\Work\ASPNET\PreCompiled.Web\PreCompiled.Web" -v / "E:\Release\PreRelease" -fixednames
E:
cd /Release/PreRelease/bin
del *.xml
cd ..
rd /s/q App_Start
rd /s/q Controllers
rd /s/q Models
rd /s/q obj
rd /s/q Properties
del *.csproj
del *.user
del Web.Debug.config
del Web.Release.config
PAUSE
參考資料：
https://msdn.microsoft.com/zh-cn/library/bb398860(v=vs.100).aspx
https://msdn.microsoft.com/zh-cn/library/ms229863(v=vs.100).aspx#findingthecorrectversion
https://msdn.microsoft.com/zh-cn/library/ms228040(v=vs.100).aspx
