前言
本文期图阐述在SP2010里面Sandboxed的原理极其相关使用。写这篇文章的时候正好遇到一个用户的case，这个case需要在某个列表里输入数据点击保存后数据能按照一定的格式插到Calendar列表里面去。当时想了很多种方法（虽然最后才意识到居然忽略了SharePoint Designer工作流，汗。。。），由于对SP2010接触不多，隐隐约约觉得Sandboxed Solution会是一种解法，之后的学习和试验证明了这个猜想，SP2010在客户端的开发里面费力很多，Client Object Model, Sandboxed Solution等为客户端的开发提供了很大的助力，我在的公司所有的IT Infrastructure都托管给了第三方的公司，所有的部署都需要经过很长的流程来在服务器端进行部署，动辄就碰到类似于财务上的季结、年结很多系统都冻结掉上线，尽管SharePoint跟这些财务系统没有半毛钱关系但城门失火殃及池鱼每次要做部署都很难，而SP2010的Sandboxed Solution还有Client Object Model将给部署带来太多的方便。罗里罗嗦很多其实只想说明这些新的特性的引进对我们日常工作的帮助会有多大。
概要
Sandboxed Solution被打包成WSP文件，里面包含编译后的类DLL，其他非编译部件以及XML描述清单文件，站点管理员或者其他有足够权限的用户可以将WSP文件上传到根站点下的Solutions Gallery，每个Sandboxed Solution都运行在独立的application domain下面这样SharePoint可以监控每个Solution的性能情况以及资源使用情况，如果超过了IT配置的限制后Code的执行将被终止。Application domain运行在隔离的进程里，使用低于web application的应用程序池帐号的权限的账户来运行。
Sandboxed Solution运行模型
当客户端的请求需要使用Sandboxed Solution Code的时候，请求首先被分发到IIS工作进程，然后IIS会转发此请求到Execution Manager，一个运行在同一个工作进程里的组件，Execution Manager将此请求转到运行SharePoint User Code Service(SPUCHostService.exe)的服务器（根据服务器场的配置不同，可以是一个web前端服务器或者一台单独的应用程序服务器），当User Code Service收到请求后它会将此请求再次转发到一个既存的Sandbox工作进程(SPUCWorkerProcess.exe)或者启动一个新的Sandbox工作进程，如果工作进程已经host了相应的Solution则请求会被直接转发到此工作进程，否则负载最小的工作进程将被优先转发，之后工作进程会创建新的applicaiton domain并加载solution assembly，如果工作进程里设置允许最大的applicaiton domain数超过设置的限制后会卸载既存的applicaiton domaim。
由于code在Sandbox的上下文中运行，其只能使用有限的SharePoint对象模型，而且不能和任何其他的API，服务或者资源交互。
Sandbox工作进程的配置文件描述了其访问SharePoint对象模型的安全策略。当Sandbox工作进程访问允许的SharePoint API子集的时候，工作进程会将请求转发给一个代理进程(SPUCWorkProcessProxy.exe)来执行SharePoint对象模型。
以下是一些常用场景Sandbox限制的描述，此表并不包括所有场景。
|
场景 |
Sandbox | 混合 | Full-Trust |
| 创建web part，从本站点内多列表读取数据 | Y | Y | Y |
| 创建web part，从同服务器场内不同站点读取多列表数据 | Y | Y | |
| 创建web part，从不同服务器场内不同站点读取多列表数据 | Y | Y | |
| 创建web part，从外部列表读取数据 | Y | Y | |
| 创建web part，和web服务或者WCF交互 | Y | Y | |
| 创建SharePoint Designer工作流 | Y | Y | Y |
| 创建沙盒工作流动作(a method call). | Y | ||
| 创建完全信任的工作流动作 | Y | Y | |
| 在SharePoint Designer创建工作流，使用完全信任的自定义code的工作流 | Y | Y | |
| 创建一个完全code的工作流 | Y | ||
| 开发一个新的列表定义 | Y | Y | Y |
| 开发一个带list item event receivers的列表定义 | Y | Y | Y |
| 部署一个带list event receivers的列表定义 | Y | Y | Y |
| 部署一个站点定义 | Y | Y | Y |
| 创建内容类型 | Y | Y | |
| 创建外部内容类型 | Y | ||
| 创建ribbon元素 | Y | Y | Y |
| 创建新的Site Actions菜单条目 | Y | Y | Y |
| 创建SharePoint列表实例 | Y | Y | Y |
| 通过程序创建SharePoint子站点 | Y | Y | Y |
| 绑定内容类型到SharePoint子站点 | Y | Y | |
| 部署新的application page | Y | ||
| 创建timer job. | Y | ||
| 创建service application. | Y |
*可视web part不能够在Sandbox里运行，原因是因为其host了ascx文件，这些文件部署在_controltemplates虚拟路径下面，而Sandbox是不允许访问外部资源的。此限制可以通过下载Visual Studio 2010 SharePoint Power Tools来绕过，此工具将ascx编译成assembly的一部分并因此而绕过。
代码访问安全限制
沙盒Solution通过受限制代码安全策略来控制，这个策略限制沙盒Solution只能访问Microsoft.SharePoint命名空间的一个子集，同时策略也阻止沙盒Solution访问外部资源或者系统。14\UserCode包含web.config文件指定了相关的CAS策略（实际里面会配置一个具体的CAS控制描述文件地址）。有两点需要注意：
- 如果不在沙盒环境内（比如将DLL部署到GAC）使用沙盒，可以包含受阻止的类型和方法；
- 沙盒里面调用的任何方法不能够包含受阻止的类型和方法，即便当方法被调用时候受阻止的类型和方法并没有被调用到。
Visual Studio 2010 SharePoint Power Tools包含了一个沙盒编译扩展，当使用受阻止的类型和方法的时候此扩展会生成编译错误。
权限限制
除了代码访问限制，沙盒工作进程使用一个受权限限制的帐号，进一步的防止沙盒对生产环境的危害，由于沙盒执行在部分信任的环境里面，任何代码集都要包含AllowPartiallyTrustedCallerAttribute。
获得用户识别
在沙盒里面，能够通过代码获取和当前请求相关的SPUser，但是不能够当前用户认证Token。大多数情况下，这个并不是个问题。
使用Event Receivers
在沙盒里只能使用三种Receiver: SPItemEventReceiver, SPListEventReceiver, SPWebReceiver，在沙盒里面不能使用对象模型注册Event receiver，比如不能使用feature receiver类在feature被激活的时候注册event receiver。但是，你能够通过在feature的element 文件里面通过描述来注册event receiver。
可以通过以下代码来判断是否在沙盒环境下面运行：
if(System.AppDomain.CurrentDomain.FriendlyName.Contains(“Sandbox”))
{
//Your code is running in the sandbox
}
访问外部数据
广义来讲，在SharePoint2010里面有两种主要的方式来访问外部数据：
- Business Data Connectivity Object Model(BDC OM)，可以使用此模型访问外部内容类型和外部列表；
- SharePoint Object Model，可以使用SPList API访问外部列表
- 实际上SPList API使用BDC OM来访问外部列表，但是在沙盒里面SPList API是可以使用的，而BDC OM不可以。
使用工作流
在沙盒里可以部署通过SharePoint Designer创建的工作流，这些工作流存储在数据库，不能通过Sandbox创建基于Code的工作流。
workflow activities和workflow actions是相关联的概念。workflow activity是继承自System.Workflow.ComponentModel.Activity的任何类。而workflow actions指的是SharePoint Designer里面使用的一个具体的可以交互的行为。workflow action可以定义在feature清单文件或者.actions文件。
部署和升级沙盒Solutions
可以通过上传相关WSP文件到根站点的Solutions Gallery，站点集管理员可以激活停用Solution。如果希望将Solution部署到多个站点需要在每个站点单独上传并激活，不过可以创建一个集中的管理Solution的地方，然后为每个站点的Solutions Gallery创建自定义的Solution Provider。
Solution监控
SharePoint通过资源点系统来监控沙盒的性能和对资源的使用。服务器场管理员可以设置一个站点集能够对资源点的每日使用限制。注意此设置是站点集级别的，所以此设置会在相应站点集的每个沙盒之间共享，站点集管理员可以监控站点集内每个沙盒Solution对资源的使用情况，如果站点集里面的Solution对资源的使用超出了设置的最大值，SharePoint会暂时在当天剩下的时间里禁止掉该站点集沙盒的使用。
资源点根据14个不同的指标来进行计算，包括CPU执行时间、内存消耗和未处理异常等。每个指标都定义了一个叫Resources Per Point，比如部署了一个叫Contoso的项目管理站点到沙盒环境，下表显示了假想情况下两个资源指标的情况：
| 资源指标 | Resources Per Point | 每日ContoSo项目Solution使用情况 | 使用了点数 |
| SharePointDatabaseQueryCount | 20个查询 | 300查询 | 15 |
| SharePointDatabaseQueryTime | 累积120秒 | 累积240秒 | 2 |
为阻止恶意的沙盒Solution造成SharePoint服务器性能不稳定，这14个资源指标都HardCode了一个叫AbsoluteLimit的属性定义了一个沙盒Solution一次请求能够消耗的资源数。如果一旦超过了这个绝对设置，SharePoint会停止这个请求并重启沙盒工作进程。比如，CPU执行时间指标默认绝对限制为60秒，如果单个请求执行时间超过了60秒，用户代码服务会停掉并重启执行这个请求的沙盒工作进程，相应的沙盒Solution不会因此而被禁止掉。
此外，用户代码服务包含一个叫做WorkerProcessExecutionTimeout的进程，默认值为30秒，如果单次请求的执行时间超过限制，