ASP.Net運行時編譯不會離開已編譯的dll，並刪除臨時文件

我們遇到了ASP.Net運行時編譯的問題。ASP.Net運行時編譯不會離開已編譯的dll，並刪除臨時文件

在IIS的開始（和重新啓動後），用戶控件和佈局編譯得很好，沒有任何問題。但是在生命週期的某個時間點，運行時編譯會停止工作。 IIS進程的重新啓動使其再次工作。

在搜索了大量不同的帖子之後，我們做了一些額外的調試，但仍然難以確定是什麼導致了我們的問題。

爲了保持這一點，我將跳過解釋我們所做的所有測試，並跳到我認爲最接近錯誤核心的位置。

我們已將我們的compilation.tempDirectory切換到此Web應用程序專用的自定義文件夾，並且已設置procmon以查看此文件夾中的所有文件更改。一旦錯誤開始發生，我們可以看到臨時文件實際寫入此驅動器，並啓動csc.exe（在此期間，conhost.exe，CcmExec.exe和許多其他進程），我們發現procmon中沒有錯誤，但在csc.exe運行後，它會刪除臨時文件而不會離開編譯版本。（和asp.net錯誤屏幕顯示我們csc.exe失敗，但不完全是失敗）。臨時文件全部被創建（除了生成的dll） - .0.cs，.1.cs，.tmp，.cmdline，.out，.err都在短時間內存在。但是在創建之後馬上中斷，它們全部被刪除，應用程序找不到它們。

有沒有人有任何線索，以什麼原因導致此失敗後，該進程運行了一段時間？如果我們在IIS重新啓動後運行它，完全相同的文件編譯就好，但過了一段時間後，似乎運行時編譯過程中的某些內容失敗，導致ASP/w3wp/csc進程刪除臨時文件的所有符號，而不是創建該DLL，並使功能失敗。

來源

2016-06-16 M.Engel

值得注意的是，這臺服務器已經運行了一年多了，而這個問題只在一個月前纔出現。雖然不能保證每天都發生，但它通常每天發生多次，需要我們重新啓動。該服務器是CM服務器（僅供內容編輯人員使用），在我們的CD服務器上運行的代碼更加繁忙，並且沒有顯示此錯誤的跡象。但是，我們的CM服務器會更容易出錯，因爲這會產生更多的用戶控制，而這些用戶控制運行得非常少，所以他們在應用程序生命週期早期編譯的機會就會減少。 –

終於搞清楚是什麼導致了我的問題。

我們安裝了一個外部模塊，它運行另一個第三方exe文件來做一些優化。運行外部程序，在應用程序池標識下啓動conhost.exe進程。

第二個第三方（exe）在某些情況下可能會因文件鎖定而失敗，這會導致exe以及conhost.exe掛起。一旦運行了足夠多的conhost.exe，應用程序池就不再允許啓動新的程序來運行運行時編譯。這導致運行時編譯失敗，Web應用程序自動清理臨時文件。

來源

2016-07-26 14:37:57

ASP.Net運行時編譯不會離開已編譯的dll，並刪除臨時文件

回答

相關問題