本主题介绍了 SharePoint 中沙盒解决方案系统的体系结构。
包括打包系统、处理模型、分页呈现系统、资源使用率限制、代码执行和访问限制以及解决方案验证框架的说明。可在 SDK 的 沙盒解决方案节点中的其他主题中找到有关所有这些主题的详细信息。
与场解决方案相比，沙盒解决方案允许网站集管理员在没有更高级别的管理员参与的情况下，在 Microsoft SharePoint Foundation 中安装自定义解决方案。但是，若要实现此自由度，必须将沙盒解决方案限于管理员可部署的内容、可执行的代码以及可访问的资源。
.gif) 注释 |
|---|
|
有时会使用术语“用户”来代替“沙盒”，尤其是在沙盒解决方案系统的对象模型中。例如，具有系统的主 API 的命名空间为 Microsoft.SharePoint.UserCode，控制沙盒解决方案执行的服务在前端 Web 服务器上的 Windows“服务”对话框中称作“SharePoint 2010 用户代码主机”。（在管理中心应用程序中，该服务称作“SharePoint Foundation 沙盒代码服务”。）这反映了现称作“沙盒解决方案”的项目的以前名称。 |
此沙盒工作进程中运行的所有代码受执行和访问约束的限制。有两个约束体系：一个约束体系仅适用于沙盒解决方案中的代码对主 SharePoint Foundation 程序集（即Microsoft.SharePoint.dll）的调用。另一个约束体系适用于所有其他 调用，包括对所有其他 SharePoint 程序集和 .NET Framework 程序集的调用。在本主题中，第一个体系称作“服务器端对象模型约束”，第二个体系称作“一般约束”。（此外，还有一些由沙盒解决方案中使用的分页呈现系统产生的杂项约束。有关详细信息，请参阅下面的分页呈现系统一节。
| 注释 |
|---|
|
这两个体系是互斥的：一般约束不 适用于对Microsoft.SharePoint.dll程序集的调用。 |
通过两种机制施加一般约束：
-
高度限制的 CAS 策略大大限制了沙盒工作进程中可执行的代码。在 %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\CONFIG 中的wss_usercode.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 程序集不具有此属性。有关具有和不具有此属性的 .NET Framework 程序集的列表，请参阅 沙盒解决方案中可用和不可用的 .NET 程序集。有关具有和不具有此属性的 SharePoint 程序集的列表，请参阅 沙盒解决方案中可用和不可用的 SharePoint 程序集。
注释CAS 策略将强名称 Microsoft Office 程序集视作例外。这些程序集授予了完全信任。
有关此 CAS 策略及其含义的详细信息，请参阅 沙盒解决方案的限制。
-
-
其次，沙盒工作进程具有一个低权限的安全令牌。
-
该令牌拒绝进程对文件系统进行读取或写入的权限。
-
该令牌拒绝进程对网络进行调用的权限。因此，只能访问运行沙盒工作进程的服务器上可用的资源。例如，无法访问外部数据库。
-
该令牌拒绝进程对注册表进行写入的权限。
-
该令牌拒绝对未在常规程序集缓存中的任何程序集进行调用的权限，即使它具有 AllowPartiallyTrustedCallersAttribute 属性也是如此，否则它将符合从沙盒工作进程进行调用的资格。
-
请记住，这些限制不 适用于对Microsoft.SharePoint.dll程序集中的 API 的调用。因此，对 GetLocalizedString 的调用可从文件系统中的资源文件读取，而对 SPList 对象的调用可读取并写入到内容数据库中，无论其所在的服务器如何。（但是，不能将文件部署到沙盒解决方案中的磁盘，因此，必须将.resx作为场解决方案单独安装。）
服务器端对象模型约束体系中的主要限制是，只能从沙盒解决方案调用Microsoft.SharePoint.dll程序集中的部分 API。调用任何禁止的 API 会引发异常（将捕获该异常，并将其作为错误报告给用户）。
以下是可访问的 SharePoint 对象模型的一些限制：
-
SPWebApplication 类不可用。此外，这意味着，沙盒解决方案无法访问其托管网站集外部的任何内容。
-
Microsoft.SharePoint.WebControls 命名空间中的所有类几乎都不可用，这意味着，您只能使用沙盒解决方案中的 ASP.NET 控件。
有关对沙盒解决方案可用的Microsoft.SharePoint.dll类的完整列表，请参阅 沙盒解决方案中可用的 Microsoft.SharePoint.dll API。
此限制由一对位于 %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\UserCode\assemblies 中的特别受限版本的Microsoft.SharePoint.dll程序集（称作填充程序 程序集）实现。这两个版本与标准Microsoft.SharePoint.dll程序集的主要差异是，它们仅包含标准版本中的部分类和成员。
这两个填充程序程序集之一由沙盒工作进程加载。另一个填充程序程序集在完全信任下运行的特殊代理进程 (SPUCWorkerProcessProxy.exe) 中加载，并由 SharePoint Foundation 沙盒代码服务管理。此外，标准Microsoft.SharePoint.dll程序集也在此代理进程中加载。
这两个填充程序程序集的主要工作是，筛选出禁止的 SharePoint 类和成员。在从沙盒工作进程中的任何代码调用Microsoft.SharePoint.dll时，它将重定向到程序集的填充程序版本。如果要调用的 API 未在填充程序程序集中，则将引发异常（将捕获该异常，并将其作为错误报告给用户）。
当沙盒解决方案调用填充程序程序集中包含的已批准的 API 时，第一个填充程序程序集会在完全信任代理进程中将此 API 传递给第二个填充程序程序集，而第二个填充程序程序集会将此 API 传递给标准Microsoft.SharePoint.dll。任何返回的结果将传递回原始调用代码。可通过 .NET 远程来实现此跨进程交互。沙盒工作进程和完全信任代理进程总是一起启动并成对出现。如果其中一个进程崩溃，则另一个进程也会停止。
服务器端对象模型约束体系中存在第二限制，该限制也由填充程序程序集强制实施。可从沙盒解决方案中调用某些 SharePoint API，但只会将针对参数的特殊限制传递给这些 API。这些输入限制由填充程序程序集强制实施，并确保在发生冲突时引发异常。在 SharePoint Foundation 2010 中，仅 SPSite(String) 和 SPSite(Guid) 构造函数属于此情况。虽然它们对沙盒解决方案可用，但只能将引用安装了沙盒解决方案的网站集的 URL 或 GUID 传递给它们。
| 注释 |
|---|
|
这是因为第二个填充程序程序集和标准Microsoft.SharePoint.dll在一般约束不适用的完全信任进程中运行。这些约束位于沙盒工作进程 中。 |
.gif) 重要信息 |
|---|
|
沙盒解决方案自身的部署阶段在沙盒工作进程中运行，并受相同执行约束的限制。例如，在部署沙盒解决方案时，无法将文件部署到磁盘。这是用户控件（ASCX 文件）不能位于沙盒解决方案中的主要原因。 |
图 1 演示如何在 HTTP 请求访问沙盒解决方案时处理该请求。
.gif)
SPUCHostService.exe、SPUCWorkerProcess.exe和SPUCWorkerProcessProxy.exe文件位于 %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\UserCode。
沙盒解决方案可通过两大方式摆脱常规限制。目前，最重要的是使用客户端代码访问无法从沙盒解决方案中的服务器端代码访问的资源。例如，沙盒解决方案可包含带 JavaScript 的自定义网页，JavaScript 可调用 SharePoint 的 JavaScript 客户端对象模型。此外，沙盒解决方案可包含承载 Microsoft Silverlight 应用程序的 Web 部件。后面的应用程序可调用 SharePoint 的 Silverlight 客户端对象模型。沙盒解决方案上的任何限制都不适用于客户端代码。不存在以下限制：代码执行限制、资源访问限制和资源使用率限制。有关详细信息，请参阅How to: Extend the Power of a Sandboxed Solution with the SharePoint Client Object Model。
沙盒解决方案体系结构还支持一种技术，沙盒解决方案可利用该技术调用在完全信任下运行的自定义操作。该技术需要开发一个服务器场解决方案，它包括派生自SPProxyOperation 的一个或多个类。其中的每个类均定义一个将在完全信任下运行的操作，并且可通过 ExecuteRegisteredProxyOperation 方法从沙盒解决方案中调用这些类。具体而言，将在运行标准Microsoft.SharePoint.dll程序集的相同代理进程 (SPUCWorkerProcessProxy.exe) 中执行这些完全信任代理操作。代理操作可将数据返回到沙盒解决方案。
图 2 演示如何在一个沙盒解决方案调用完全信任代理时处理访问该沙盒解决方案的请求。
.gif)
前面的说明可能给您留下以下印象，借助此技术，总是由同一开发团队来开发服务器场和沙盒解决方案。实际上，可以专门开发包含代理操作类的场解决方案以向任一和所有需要这些服务的沙盒解决方案（包括由其他团队开发的沙盒解决方案）提供特定操作。例如，由于沙盒解决方案无法写入 SharePoint ULS 日志，因此对沙盒解决方案公开代理日志记录操作的场解决方案会很有用。
有关开发和调用完全信任代理操作的详细信息，请参阅 Sandboxed Solutions in Partnership with Full-Trust Proxies in SharePoint 2010 （该链接可能指向英文页面）和同一节点中的其他主题。