SharePoint 沙盒解决方案 VS 场解决方案

博客地址 http://blog.csdn.net/foxdave

最近看书正好看到了关于沙盒解决方案的介绍，便整理记录一下。

虽然沙盒解决方案已经在最新的SharePoint开发中被否决弃用了(被APP取代)，但是我觉得一些简单的东西用也无妨，比如霖雨大神文章中提到的那种情景。

具体内容参阅“在 SharePoint 2013 中选择正确的 API 集”。

我们先来回顾一下SharePoint开发接口历程

●SharePoint 2007（2007之前的版本不是很熟悉，但应该是跟2007类似的）：此时是场解决方案的天下（或者说，沙盒解决方案还没有），而且WSP解决方案包需要手工生成，是简陋的原始的；同时，SharePoint提供了WebService供远程调用，也可以做很多操作。

●SharePoint 2010：沙盒解决方案出现了。同时，API中也新增了客户端对象模型（CSOM）。借助Visual Studio 2010，解决方案的生成也变得智能化，把开发者从繁琐的打包部署过程中解放出来，大大缩短了调试时间。具体内容参阅“决定要使用的 SharePoint 2010 API”。

●SharePoint 2013：SharePoint APP问世了，伴随而来的开发接口也变得丰富起来，具体内容参考上面的链接。

回到我们的重点，沙盒解决方案。

沙盒是一个受限制的执行环境，可使程序仅访问某些资源，并使在沙盒中发生的问题不会影响服务器环境的其余部分。部署到沙盒中的解决方案称为沙盒解决方案，它们不能使用某些计算机和网络资源，也不能访问它们部署到的网站集以外的内容。

因为沙盒解决方案不会影响整个服务器场，因此不必由服务器场管理员进行部署。沙盒解决方案可以由网站集管理员部署，或者，在某些情况下，可由具有对网站集根目录的完全控制权限级别的用户部署。但是，只有服务器场管理员才能配置沙盒解决方案相关设置（如负载平衡、层、配额和资源点），也只有服务器场管理员才能提升沙盒解决方案，使其直接在沙盒环境之外的服务器场中运行。

沙盒解决方案适合在以下两种常见情况下使用：

• 组织希望在 SharePoint Server 生产网站上运行员工代码，并且此代码没有经过严格的评审和测试。
• 宿主希望让所承载的 SharePoint Server 网站的所有者上载和运行自定义代码。

使用沙盒解决方案的主要好处如下：

• 可以将沙盒解决方案添加到 SharePoint Server 生产环境中，而不存在影响沙盒外的进程的风险。
• 网站集管理员可以部署沙盒解决方案。这将使服务器场管理员从此项任务中解脱出来。
• 由于沙盒在可受配额限制的单独进程中运行，并且可以监控其对服务器场的影响，因此增加了可伸缩性和灵活性。
• 可以将解决方案从沙盒中移出并直接在场中运行，而不必修改或重新编译解决方案。

因为沙盒解决方案的局限性，必然有一些东西是它无法实现的，这些内容包括：

?连接到不在本地服务器场上的资源。
?访问数据库。
?更改线程模型。
?调用非托管代码。
?写入到磁盘。
?访问不同网站集中的资源。

下面详细比较场解决方案与沙盒解决方案的区别

场解决方案：

运行在IIS工作进程（W3WP.EXE）中。

运行在场解决方案中的代码会影响整个场。

部署或回收任何功能时，都会造成整个应用程序池被回收。

由于范围为场级别，他们对所有的资源都有完全信任的访问权限。

沙盒解决方案：

运行在SharePoint用户代码解决方案工作进程（SPUCWorkerProcess.EXE）中。

该进程运行在CAS策略下被限制访问沙盒之外的任何资源，所以它从来不会重启IIS应用程序池。

运行的代码只会影响解决方案所在的网站集。

注意：

场解决方案是安装和部署、沙盒解决方案是上传和激活。

沙盒解决方案不能创建在TEMPLATES/_LAYOUTS下的应用程序页，部署的沙盒解决方案没有访问文件系统物理路径的权限。

沙盒解决方案无法创建可视化Web部件（在SharePoint 2013中可以，但是要确保使用的类对象没有被限制并且没有使用layout文件夹）。

沙盒解决方案无法使用代码链接外部的Web服务或数据库。

有些API的类无法使用。

补充阅读：

沙盒解决方案概述 (SharePoint Server 2010)

可以在沙盒解决方案中实现哪些内容

沙盒解决方案的限制

Top 10 reasons to use Sandboxed Solutions

Top 10 things to consider when writing SandBoxed Solutions