SharePoint 2010 Sandboxed系列－未完待续

前言

本文期图阐述在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限制的描述，此表并不包括所有场景。