SharePoint，VirtualPathProviders和應用程序重新啓動

Question

鑑於卸載動態編譯程序集（以回收內存）的唯一方法是卸載應用程序域，SharePoint如何依靠VirtualPathProviders，特別是母版頁和頁面佈局，而不會碰到這個限制？

重新啓動可以通過各種設置延遲，但在主頁面和頁面佈局更新和頻繁發佈時無法完全避免，是否正確？

（是否缺乏這方面的信息歸因於它在發佈模式中不常見的更多理論限制？您是否親自注意到掌握頁面或佈局導致應用程序不穩定的變化率？如果SharePoint帶有警告？）

任何利用動態WebForms（包括默認情況下，MVC視圖）的CMS-esque功能容易受到變化率不穩定的影響？

更新上非編譯頁：

無編譯頁 在ASP.NET 2.0中，編譯模型已顯著重構和擴展。網站預編譯可能是新功能最受歡迎和最響亮的要求。另一個非常有趣的功能是不編譯頁面。他們是特殊的頁面，只是永遠不會被編譯。那麼，沒有編譯頁面的最終目的是什麼？它們和靜態HTML頁面有什麼區別？ 首先，通過將@Page指令中的CompilationMode屬性設置爲Never從而創建一個非編譯頁面。當請求不編譯頁面時，不會創建頁面程序集並將其保存到磁盤。而是將頁面構建器組件的一個實例緩存在內存中，並用於爲每個請求創建頁面輸出。頁面構建器是一個特殊的組件，它在構建頁面控制樹時支持頁面解析器。編譯打開時，控制樹用於獲取要編譯的類。編譯關閉時，控件樹用於獲取標記。不用說，如果您想讓程序員將自己的代碼附加到頁面上，那麼類是必需的。無編譯頁面由服務器控件和文字組成，但不包含任何代碼。

不編譯頁面不適用於每個應用程序。它們專門用於改進具有數千頁網頁的超大型網站的可擴展性。無編譯頁面不能綁定到代碼文件，也不能包含服務器端塊。在非編譯頁面中唯一可執行的代碼段是$ -expressions。沒有編譯頁面有兩個主要優點。在像SharePoint這樣的安全環境中，無編譯頁面會阻止開發人員編寫可能會導致宿主環境出現問題的潛在錯誤代碼，甚至會導致問題無法解決。在大型的基於內容的網站中，無編譯頁面避免了編譯數千頁的需要。

參考文獻：

1 - http://haacked.com/archive/2009/04/22/scripted-db-views.aspx

Answer 1

首先要注意的是，自定義頁面（可能是masterpages或頁面佈局）總是存儲在數據庫中。

頁面請求週期與SPVirtualPathProvider路由請求的方式不同，不同於香草ASP.net版本。一旦發現請求是針對自定義頁面進行的（相對於位於文件系統中的未定製頁面，並且遵循常規的ASP.net頁面編譯模式），頁面的代碼將從數據庫中提取出來，並傳遞給ASP .net運行時，並以「無編譯模式」進行解析。「

下面是過程的視覺再現時的定製頁面的請求時：

讚美Shivprasad Koirala

Here is also good description of ASP.net's no compile mode

沒有編譯頁數：

沒有編譯頁面能夠改進 比例爲大型場所的 頁1000，作爲窗口對加載到一個應用程序的DLL 數量和PERF 會隨着你的限制達到此限制。設置 <％@ Page CompilationMode =「自動」 ％>指令編譯 有條件地獲得縮放 好處沒有限制的代碼。 您也可以將CompilationMode設置爲 「從不」，以防止正在編譯的頁面從 開始。您可以在Web.config中的<頁面/ >部分 上將此 屬性設置爲應用於 應用程序中的所有頁面。當它包含用戶 代碼時，一個不編譯頁面將會發出錯誤 。

所以這基本上解決了您關於過度應用重置提到的問題在卸載時/加載應用程序域由於多個自定義實時發生的（問題的任何CMS建立在ASP.net運行必須解決）。

在此之上;以這種方式存儲定製內容時，您可以「免費」獲得SQL Server的多用戶功能和可伸縮性;而不是文件系統方法，這將需要額外的努力來管理鎖定。

Answer 2

發現這個1的一個很好的解釋：

作爲一名開發人員，你的第一反應 這可能是質疑爲什麼 定製頁 無編譯模式進行處理。你的直覺可能是 告訴你，編譯頁面比沒有編譯頁面運行更快 。然而， 非編譯頁面可以更有效率 並且在某些 方案中更具可擴展性。特別是在 的大WSS環境中，其中 數量的自定義頁面可以達到 成千上萬或數十個成千上萬個 。

沒有編譯頁面可以加載到內存中，然後以 不可能的方式卸載 因爲編譯頁面是不可能的。NET Framework並不真正支持從內存中卸載程序集DLL 的 概念。最接近的相當於 將回收當前的 Windows進程或當前的.NET AppDomain。但是，這種類型的回收包括從內存中卸載所有組裝的DLL，而不僅僅是 那些最近未使用的組件DLL。此外，.NET 框架會將 數量的程序集DLL的上限設置爲可加載到.NET AppDomain中的 。

無編譯頁面提供更高級別的可伸縮性，因爲它們不需要將新的 程序集DLL或託管類程序加載到 內存中。相反， 非編譯頁面的處理涉及將控制樹加載到內存中。 WSS可以 更有效地管理與 定製頁面相關的 控制樹的內存使用 ，因爲它們未被編譯到 彙編DLL中。例如，一旦WSS 已經完成處理定製的 頁面，它可以卸載該頁面的控件 樹以釋放內存用於其他 目的。此外，免編譯 頁消除了編譯過程需要經過 ，其中 實際上爲首次訪問時的頁面提供了更快的響應 次。

它們的關鍵之處在於，可以卸載無法編譯的頁面（關聯的頁面構建器可以被卸載），這對編譯頁面來說是不可能的。儘管它的核心是可擴展性度量（在此模型下可以處理更多頁面），而不是性能增強（初始設置後，編譯頁面應該比未編譯頁面更好）。

1 - http://chiragrdarji.wordpress.com/2007/10/12/page-ghosting-unghosting-and-effect-of-pageghosting-on-performance-in-sharepoint-2007/