為什么aspnet_compiler.exe這么慢（可以更快）？

Question

在我們的構建過程中，我們對我們的網站運行aspnet_compiler.exe ，以確保ASP.NET / MVC中所有后期綁定的內容實際構建（我對ASP.NET一無所知但我確信這是必要的，以防止在運行）。

我們的網站規模相當大，有幾百頁/視圖/控件/等。 然而，在10-15分鍾范圍內所花費的時間似乎過多（作為參考，這比整個解決方案需要大約40個項目的編譯時間更長，我們只是預編譯了兩個網站項目）。

我懷疑硬件是問題，因為我運行的是最新的四核英特爾芯片，配備4GB內存和WD Velociraptor 10,000rpm硬盤。 而奇怪的部分是EXE似乎沒有使用太多的CPU（1-5％）並且似乎也沒有做太多的I / O.

那么......這是一個眾所周知的問題嗎？ 為什么這么慢？ 有沒有辦法加快速度？

注意：為了澄清人們已經回答的一些事情，我不是在談論Visual Studio中的代碼編譯。 我們已經在使用Web應用程序項目了，編譯速度不是問題。 問題是在已經編譯這些項目之后預先編譯網站（ 有關詳細信息，請參閱此MSDN頁面 ）作為開發構建腳本的一部分。 我們正在執行就地預編譯，而不是將文件復制到目標目錄。

Answer 1

切換到Roslyn編譯器最有可能顯着改善預編譯時間。 這是一篇很好的文章： http ： //blogs.msdn.com/b/webdev/archive/2014/05/12/enabling-the-net-compiler-platform-roslyn-in-asp-net-applications。 aspx 。

除此之外，還要確保通過在編譯元素上將批處理屬性設置為true來啟用批處理編譯。

Answer 2

簡單地說，每當aspnet_compiler開始預編譯任何單獨的aspx頁面時， aspnet_compiler使用“全局編譯器鎖”。 它基本上只允許按順序編譯每個頁面。

這是有原因的（雖然我個人不同意） - 主要是為了檢測和防止導致無限循環排序的循環引用，以及確保在編譯需求頁​​面之前正確構建所有依賴項，它們避免很多“令人討厭的CS問題”。

上次我在一家網絡公司工作時，我曾經開始編寫一個大量分叉的aspnet_compiler.exe版本，但卻被“真正的工作”所束縛，從未完成它。 最大的問題是ASPX頁面：你可以將HELL並行化的MVC / Razor，但ASPX解析/編譯引擎大約是內部和私有類/方法的20級。

Answer 3

1. 編譯器應為每個.aspx頁面生成第二個代碼隱藏文件， 請檢查
2. 在編譯期間，aspnet_compiler.exe會將所有網站文件復制到輸出目錄，包括css，js和images。

使用Web應用程序項目而不是Web站點模型，您將獲得更好的編譯時間。

Answer 4

我沒有針對這個編譯器的任何特定熱門技巧，但是當我遇到這種問題時，我運行ProcMon來查看該進程在機器上正在做什么，並且我運行Wireshark來檢查它是否花費了很多時間 - 對某個注冊表項或環境變量中引用的長時間遺忘的計算機的某些網絡訪問。

Answer 5

只需2美分。

減慢ASP.NET視圖預編譯的一個-fixednames是aspnet_compiler.exe的-fixednames命令行選項。 如果您使用的是Razor / MVC，請不要使用它 。

從Visual Studio發布wep應用程序時，請確保選擇“不合並”，並且不要選擇“創建單獨的程序集”，因為這是導致全局鎖定並減慢速度的原因。

更多信息請訪問https://msdn.microsoft.com/en-us/library/hh475319(v=vs.110).aspx