???? 上文我們了解了一個外部Http Request進入IIS 工作進程(W3WP)的處理與執行信任模型，這個階段是Sharepoint的四種執行模型都必須經過的處理階段，其中Sharepoint場解決方案與任何 ASP.NET 應用程序一樣就是在 IIS 工作進程(w3wp)中運行的，所以上文也就包含了場解決方案的處理與執行信任模型。

???? 這里繼續我們的話題，就是看看Sharepoint的沙盒解決方案在這方面是什么情況。

???? 沙盒解決方案是 SharePoint 2010 的新功能。沙盒解決方案是直接部署到網站集根網站中（The top Website of the Site Collection）的指定庫的資源集合。此庫稱為"解決方案庫(Solution Gallery)"。我們可以像場解決方案一樣，將沙盒解決方案打包為 SharePoint 解決方案包 (WSP)。不過，可以通過 Web 用戶界面 (UI) 直接上傳 WSP 來部署沙盒解決方案，而不必物理訪問服務器文件系統，也不必 IT 團隊參與。相反，網站集管理員確定誰有權限向其網站集添加沙盒解決方案。所以，沙盒解決方案對開發和管理團隊是很有誘惑力的。

一、IIS工作進程(w3wp)交權給執行管理器(Execution Manager)

???? 如果用戶的Http 請求(Http Request)中包含有對沙盒解決方案的處理模型，Http請求到了IIS工作進程(w3wp), IIS工作進程(w3wp)就會發現，這個請求里涉及到沙盒處理模型，這時，IIS工作進程(w3wp)就會調用它里面運行的執行管理器(Execution Manager)，由執行管理器(Execution Manager)來接管下一步的處理權移交。如下圖:

???? 上圖中的SPUCHostService.exe、SPUCWorkerProcess.exe 和 SPUCWorkerProcessProxy.exe 文件位于

%ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\UserCode。

?

二、執行管理器(Execution Manager)交權給沙盒工作進程(SPUCWorkerProcess)

???? IIS 工作進程中運行的 SharePoint執行管理器(Execution Manager)負責查找沙盒解決方案的代碼將在其中運行的沙盒工作進程(SPUCWorkerProcess)（如果未運行任何沙盒工作進程，則負責啟動一個沙盒工作進程）。

???? 請注意，執行管理器(Execution Manager)啟動或定位的沙盒工作進程(SPUCWorkerProcess)并不一定是在同一服務器上，這可以從上面的示意圖中看出。

2.1沙盒工作進程(SPUCWorkerProcess) 宿主機的要求

???? 一般而言，執行管理器(Execution Manager)會在Sharepoint服務器場中任何運行 SharePoint Foundation 沙盒代碼服務 (SPUCHostService: Sharepoint User Code Host Service) 的服務器上啟動此沙盒工作進程(SPUCWorkerProcess)。

???? 在 Windows"服務"對話框中，它稱作"SharePoint 2010 用戶代碼主機"服務，如下圖:

???? SharePoint Foundation 沙盒代碼服務(SPUCHostService)在服務器場帳戶下運行，此帳戶與應用程序池帳戶（Application Pool Account）擁有一樣的權限，此帳戶歸屬于沙盒代碼服務所運行的宿主服務器上的WSS_WPG、WSS_ADMIN_WPG、IIS_USERS這三個組。

2.2運行Microsoft SharePoint Foundation沙盒代碼服務(SPUCHostService)物理服務器的定位模式

???? 運行 SharePoint Foundation 沙盒代碼服務的服務器可以是（但并不一定是）運行 IIS 工作進程的前端 Web 服務器?？稍诠芾碇行膽贸绦騼扰渲靡褂玫姆掌?#xff0c;這種配置有兩種選項。

???? I、"本地模式(local mode)":這意味著將在運行 IIS 工作進程(W3WP)的同一前端 Web 服務器上處理對沙盒解決方案的每個請求，即本地處理。

???? II、"遠程模式(remote mode)"（有時稱作"相似性模式[affinity mode]"）:在此模式中啟動每個沙盒進程，執行管理器將查找運行 SharePoint Foundation 沙盒代碼服務的服務器，該服務器已在其 SPUCWorkerProcess進程內為相同的沙盒解決方案創建了 一個應用程序域(application domain)。（如果其他網站集的另一個用戶之前已請求該相同的沙盒解決方案，則將出現此情況）。如果存在一個匹配的應用程序域，則會將請求發送到相同的應用程序域以進行處理。如果運行 SharePoint Foundation 沙盒代碼服務的任何服務器都不具有沙盒解決方案的應用程序域，則執行管理器會將請求分配給這些服務器中最閑的服務器。之后，該服務器將創建所需的應用程序域并處理對沙盒解決方案的請求。

????????? 不管使用的是"本地模式"還是"相似性模式"，沙盒工作進程中的應用程序域(application domain)都將在處理完請求后保持活動狀態，且如果存在對相同沙盒解決方案的其他請求，則將重用該應用程序域。

????????? 默認情況下，由給定服務器處理的所有沙盒解決方案都在相同的沙盒工作進程中運行，但這種配置是可以通過object Model進行修改的。每個沙盒解決方案會在常規進程(common process)中獲取其自己的應用程序域(application domain)，而這種配置也是可以通過object Model進行修改的

2.3 運行"Microsoft SharePoint Foundation沙盒代碼服務"物理服務器的分配方法

?????? 如果你的服務器場包含了若干臺服務器，那么你既可以在所有物理服務器上啟動"Microsoft SharePoint Foundation沙盒代碼服務"，也可以只選擇在某幾臺應用服務器上啟動"Microsoft SharePoint Foundation沙盒代碼服務"。

?????? 當然你也可以準備一臺配置比較高的服務器加入到服務器場中專門用于運行"Microsoft SharePoint Foundation沙盒代碼服務"。這樣，無論服務器場中的哪一臺前端服務器需要運行沙盒解決方案中的自定義代碼，這些請求都會被發送到這臺強大的物理服務器上進行處理。

三、沙盒工作進程(SPUCWorkerProcess) 內的代碼執行和安全模型

?????? 前面我們提到，沙盒方案其實就是一種"受限"方案，正因為受限，所以才安全。所以，在沙盒工作進程(SPUCWorkerProcess)中運行的所有代碼會受到執行和訪問約束的限制。

?????? 這種約束有兩個體系：

??????? 3.1、第一個體系稱作"服務器端對象模型約束"

?????????????? 此約束體系僅適用于沙盒解決方案中的代碼對主 SharePoint Foundation 程序集（即 Microsoft.SharePoint.dll）的調用，其調用只作用于Microsoft.SharePoint.dll中的部分object model。這種約束不僅僅是指從用戶創建的Sharepoint Solution中調用Microsoft.SharePoint.dll，而且還包括從Sharepoint的其它程序集(eg: Microsoft.Sharepoint.Linq.dll)來調用Microsoft.SharePoint.dll程序集。

???????????? 3.1.1服務器端對象模型約束體系中的主要限制是:

??????????????????? 只能從沙盒解決方案調用 Microsoft.SharePoint.dll 程序集中的部分 API。調用任何禁止的 API 會引發異常（將捕獲該異常，并將其作為錯誤報告給用戶）。

??????????????????? 以下是可訪問的 SharePoint 對象模型的一些限制：

• SPWebApplication 類不可用。此外，這意味著，沙盒解決方案無法訪問其托管網站集外部的任何內容。
• Microsoft.SharePoint.WebControls 命名空間中的所有類幾乎都不可用，這意味著，您只能使用沙盒解決方案中的 ASP.NET 控件。

?????????????3.1.2 服務器端對象模型約束通過以下機制來施加:

?????????????????? 此限制由一對位于%ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\UserCode\assemblies 中的特別受限版本的 Microsoft.SharePoint.dll 程序集（稱作填充程序 程序集）實現。這兩個版本與標準 Microsoft.SharePoint.dll 程序集的主要差異是，它們僅包含標準版本中的部分類和成員。

?????????????????? 這兩個填充程序程序集之一由沙盒工作進程(SPUCWorkerProcess)加載，另一個填充程序程序集在完全信模式下運行的特殊代理進程 (SPUCWorkerProcessProxy) 中加載，并由 SharePoint Foundation沙盒代碼服務(SPUCHostService)管理。

???????????????? 此外，標準 Microsoft.SharePoint.dll 程序集也在此代理進程中加載。

????????????????? 這兩個填充程序程序集的主要工作是:

????????????????? I、篩選出禁止的 SharePoint 類和成員

???????????????????? 在從沙盒工作進程中的任何代碼調用 Microsoft.SharePoint.dll 時，它將重定向到程序集的填充程序版本。如果要調用的 API 未在填充程序程序集中，則將引發異常（將捕獲該異常，并將其作為錯誤報告給用戶）。

???????????????????? 當沙盒解決方案調用填充程序程序集中包含的已批準的 API 時，第一個填充程序程序集會(它由沙盒工作進程SPUCWorkerProcess加載)在完全信任代理進程中將此 API 傳遞給第二個填充程序程序集（它由特殊代理進程?????? (SPUCWorkerProcessProxy)加載），而第二個填充程序程序集會將此 API 傳遞給標準 Microsoft.SharePoint.dll。任何返回的結果將傳遞回原始調用代碼。可通過 .NET 遠程來實現此跨進程交互。

??????????????????? 沙盒工作進程和完全信任代理進程總是一起啟動并成對出現。如果其中一個進程崩潰，則另一個進程也會停止。

????????????????? II、對傳遞給Sharepoint API的參數進行特殊限制

??????????????????? 該限制也由填充程序程序集強制實施。我們可似從沙盒解決方案中調用某些 SharePoint API，但只會將針對參數的特殊限制傳遞給這些 API。這些輸入限制由填充程序程序集強制實施，并確保在發生沖突時引發異常。在 SharePoint Foundation 2010 中，僅 SPSite(String) 和 SPSite(Guid) 構造函數屬于此應用情況。雖然它們對沙盒解決方案可用，但只能將引用安裝了沙盒解決方案的網站集的 URL 或 GUID 傳遞給它們。

???????????????????? 因為第二個填充程序程序集和標準 Microsoft.SharePoint.dll 在完全信任的進程中運行，所以上述限制就不 適用于對 Microsoft.SharePoint.dll 程序集中的 API 的調用，更進一步說就是通過這些API就可以完成某些在沙盒方案中被禁止的操作。比如: 對 GetLocalizedString 方法的調用可從文件系統中的資源文件讀取，而對 SPList 對象的調用可讀取并寫入到內容數據庫中，無論其所在的服務器如何。（但是，不能將文件部署到沙盒解決方案中的磁盤，因此，必須將 .resx 作為場解決方案單獨安裝。）

?

????????? 3.2、第二個體系稱作"一般約束"

??????????????? 此約束體系適用于所有其他 調用，包括對所有其他 SharePoint 程序集和 .NET Framework 程序集的調用，只要不是對主 SharePoint Foundation 程序集（即 Microsoft.SharePoint.dll）的調用就行。

??????????????? 上面這兩個體系是互斥的：一般約束不 適用于對 Microsoft.SharePoint.dll 程序集的調用，你只能二選 一。此外，還有一些由沙盒解決方案中使用的分頁呈現系統產生的雜項約束。

????????????????? "一般約束"通過兩種機制來施加：

?????????????? I、第一種機制

??????????? 是通過在wss_usercode.config 文件所定義的高度限制的?CAS 策略來大大限制沙盒工作進程中可執行的代碼，此文件在%ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\CONFIG 中定義,并在 %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\UserCode 下的 web.config 文件中引用了該策略。（微軟不支持更改此文件。）由 CAS 策略施加的限制如下：

• 沙盒中的代碼不能調用非托管代碼。
• 沙盒中的代碼不能調用 Microsoft .NET Framework 3.5 反射 API。
• 沙盒中的代碼只能調用具有 AllowPartiallyTrustedCallersAttribute 屬性的 .NET Framework 3.5 程序集。這將阻止對約三分之二的 .NET Framework 3.5 API（例如，包括 System.Printing）的訪問。此外，一些 SharePoint 程序集不具有此屬性。

???????????????????? CAS 策略將強名稱 Microsoft Office 程序集視作例外。這些程序集授予了完全信任。

????????????? II、第二種機制

??????????????????? 是通過安全令牌來實施，即給沙盒工作進程賦予一個低權限的安全令牌。

• 該令牌拒絕進程對文件系統進行讀取或寫入的權限。
• 該令牌拒絕進程對網絡進行調用的權限。因此，只能訪問運行沙盒工作進程的服務器上可用的資源。例如，無法訪問外部數據庫。
• 該令牌拒絕進程對注冊表進行寫入的權限。
• 該令牌拒絕對未在常規程序集緩存(GAC)中的任何程序集進行調用的權限，即使它具有 AllowPartiallyTrustedCallersAttribute 屬性也是如此，否則它將符合從沙盒工作進程進行調用的資格。

??????????????????? 沙盒解決方案自身的部署階段在沙盒工作進程中運行，并受相同執行約束的限制。例如，在部署沙盒解決方案時，無法將文件部署到磁盤。這是用戶控件（ASCX 文件）不能位于沙盒解決方案中的主要原因。

?

四、關于沙盒方案資源使用的限制

??????????????? 沙盒方案既然把一定的權力下放，但由此卻帶來潛在的問題，那就是對Sharepoint資源的分配。設想如果不加控制，那么某個用戶就可能把特定的資源消耗殆盡。所以，Sharepoint也就自然引入了針對資源的使用限制，具體有如下三條限制規則

• 每個請求（請求遭到處罰）：對于完成沙盒解決方案所需的時間有一個硬性限制。默認情況下，此時間限制為 30 秒。如果沙盒解決方案超出了該限制，則將終止請求（而非沙盒工作進程）。（此限制是可配置的，但只能通過針對對象模型的自定義代碼進行此操作。對象模型的相關部分對沙盒解決方案不可用，因此，任何沙盒解決方案都無法更改此限制。）
• 每個請求（進程遭到處罰）：有一組適用于請求的附加資源限制（共 15 條）。如果請求超出某個限制，則將終止進程（以及進程中運行的所有 沙盒解決方案）。
• 每天/每個網站集（網站集遭到處罰）：每個網站集均受可配置的每日"資源點"最大數的限制。這些點基于某種算法進行累計，該算法會考慮網站集中安裝的沙盒解決方案對 15 類資源的使用。當網站集超出其允許的最大點數時，該網站集中的所有沙盒解決方案將終止，且在剩余時間內再也無法運行。

五、沙盒的分頁呈現

??????? 當客戶端計算機請求包含沙盒解決方案中的組件（例如，沙盒解決方案中部署的 Web 部件）的 SharePoint 頁時，SharePoint 會呈現多個頁對象。其中一個頁對象在 Microsoft ASP.NET 工作進程 (w3wp.exe) 中呈現，而其他頁對象在沙盒工作進程中呈現。所有非沙盒組件會在 ASP.NET 工作進程中的頁上呈現，而第一個沙盒組件會在沙盒工作進程中的一個頁對象上呈現。在完全呈現沙盒工作進程中的該頁時，會將該頁并入 ASP.NET 進程中的頁對象。如果用戶請求的頁上有多個沙盒組件，則將在這些組件在沙盒工作進程中所對應的頁對象上單獨呈現它們。反過來，每個此類頁對象將并入 ASP.NET 進程中的頁對象。

六、擺脫沙盒限制

???????沙盒解決方案可通過兩大方式擺脫常規限制。

?????? ?1.使用客戶端代碼訪問無法從沙盒解決方案中的服務器端代碼訪問的資源。

????????? 例如，沙盒解決方案可包含帶 JavaScript 的自定義網頁，JavaScript 可調用 SharePoint 的 JavaScript 客戶端對象模型。此外，沙盒解決方案可包含承載 Microsoft Silverlight 應用程序的 Web 部件。后面的應用程序可調用 SharePoint 的 Silverlight 客戶端對象模型。沙盒解決方案上的任何限制都不適用于客戶端代碼。不存在以下限制：代碼執行限制、資源訪問限制和資源使用率限制。

?????? ? 2.通過完全信任代理。

???????? 即開發一個服務器場解決方案，它包括派生自 SPProxyOperation 的一個或多個類，其中的每個類均定義一個將在完全信任下運行的操作，并且可通過 ExecuteRegisteredProxyOperation 方法從沙盒解決方案中調用這些類。具體而言，將在運行標準 Microsoft.SharePoint.dll 程序集的相同代理進程 (SPUCWorkerProcessProxy.exe) 中執行這些完全信任代理操作。代理操作可將數據返回到沙盒解決方案。

七、Sharepoint執行的其它情況

??????? 并不是所有的Sharepoint 實施都依賴于IIS工作進程(IIS worker process),沙盒工作進程(sandboxed worker process)或其代理進程(proxy process)。下面就是一些例子:

• Sharepoint的Timer Service,用于執行預設的作業，它可以影響其它服務，它以Farm帳戶運行在owstimer進程下。
• SharePoint的Tracing Service ，以本地的服務帳戶(local service account)運行在wsstracing進程下。
• SharePoint Administration Service 以本地系統帳戶(local system account)運行在wssadmin進程下。

總結

以上是生活随笔為你收集整理的Sharepoin学习笔记—架构系列--03 Sharepoint的处理(Process)与执行模型(Trust Model) 2的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。