●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的类无法使用。
方面 | 场 | 沙盒 |
---|---|---|
部署过程 |
添加解决方案,然后将它部署到场中。 |
将解决方案上载到网站集,然后在网站集中将其激活。 |
可以部署的人 |
服务器场管理员。 |
如果解决方案中包含一个程序集,则只有网站集管理员可以部署它。如果解决方案不包含程序集,则拥有对网站集根目录的完全控制权限级别的用户可以部署它。 |
数据访问 |
不受限制。 |
解决方案只能访问部署到的网站集中的内容。 |
运行解决方案的进程 |
不受限制的 IIS 工作进程,或将解决方案部署到的任何进程。 |
单独的权限受限制的工作进程。 |
代码访问安全性 |
解决方案开发人员在将解决方案打包时可以设置代码访问安全性策略。 |
受限制。 |
监控 |
不受监控。 |
受监控,并受服务器场管理员设置的配额限制。 |
负载平衡 |
不定,具体取决于解决方案的种类。 |
可从非沙盒解决方案单独配置。 |
解决方案功能 |
不受限制。 |
受限制。 |
补充阅读:
沙盒解决方案概述 (SharePoint Server 2010)