Title: SharePoint 2010 Sandboxed Solutions
Introduction: How many times ( as a developer ) have you felt you wanted to have control on testing, staging or productions servers to deploy your solution? and how many times you might have bothered your engineering team for deployment? Similarly, how many times the engineering team might have cursed you for going to them many times to redeploy your solutions? Sounds familiar situation? Well with the introduction of Sandboxed Solutions, its a great relief to both the teams. Lets see in short in the post and I will write separately on each topic in other posts.
Sandboxed Solutions: With elevated previlages ( site collection administrators ), now you can deploy your solutions (.wsp) at the site collection level and fully control them. So, all you need is to request your engineering groups to add you to the Site collection administrators group on the target site collection. With SB Solutions, one can guarentee trust (partial) as well as protection to the farm. Since the SBS's work on a site collection, if any thing goes wrong only that site collection is compromised and would isolate the other Site collections, Web Application as well as Farm. SBS works on a different thread (SPUCWorkerProcess) and doesnt run on the same app pool. This isolation guarentees further more safety.
Build - Deploy: With VS 2010 one can opt for creating a SB Solution Project (default). However when the same solution is deployed at Farm Level, it runs with full trust where as at the site collection level it runs under partial trust. The output of the VS project would be a .wsp which you can upload to the Solutions store under the site collection. You can as well directly use the deploy option of VS however it may not be a suitable for staging and production deployments. You would simple Activate it ( equivalent to deploying the .wsp ) to run your underneath resources. When you donot need it, simply De-Activate the same.
Limitations: You cannot acheive everything using SBS's. As mentioned earlier since its partially trusted donot assume you can attempt to write everything using SBS. Here is list of ( some of ) what you can create
Monitoring and Validating: Farm Admins can monitor using the site quota's under CA and specify locks. Alternatively, using SPSolutionValidator Farm admins can monitor and validate the solutions that allow only code signed with a particular certificate to run.
Introduction: How many times ( as a developer ) have you felt you wanted to have control on testing, staging or productions servers to deploy your solution? and how many times you might have bothered your engineering team for deployment? Similarly, how many times the engineering team might have cursed you for going to them many times to redeploy your solutions? Sounds familiar situation? Well with the introduction of Sandboxed Solutions, its a great relief to both the teams. Lets see in short in the post and I will write separately on each topic in other posts.
Sandboxed Solutions: With elevated previlages ( site collection administrators ), now you can deploy your solutions (.wsp) at the site collection level and fully control them. So, all you need is to request your engineering groups to add you to the Site collection administrators group on the target site collection. With SB Solutions, one can guarentee trust (partial) as well as protection to the farm. Since the SBS's work on a site collection, if any thing goes wrong only that site collection is compromised and would isolate the other Site collections, Web Application as well as Farm. SBS works on a different thread (SPUCWorkerProcess) and doesnt run on the same app pool. This isolation guarentees further more safety.
Build - Deploy: With VS 2010 one can opt for creating a SB Solution Project (default). However when the same solution is deployed at Farm Level, it runs with full trust where as at the site collection level it runs under partial trust. The output of the VS project would be a .wsp which you can upload to the Solutions store under the site collection. You can as well directly use the deploy option of VS however it may not be a suitable for staging and production deployments. You would simple Activate it ( equivalent to deploying the .wsp ) to run your underneath resources. When you donot need it, simply De-Activate the same.
Limitations: You cannot acheive everything using SBS's. As mentioned earlier since its partially trusted donot assume you can attempt to write everything using SBS. Here is list of ( some of ) what you can create
- Web Parts ( not visual webparts )
- Site Pages ( not application pages with code behind )
- List Definitions
- Event and Feature receivers
- Infopath form services
- Custom Actions
- Content Type and Site Columns
- JS, AJAX, SilverLight, jQuery ...
Monitoring and Validating: Farm Admins can monitor using the site quota's under CA and specify locks. Alternatively, using SPSolutionValidator Farm admins can monitor and validate the solutions that allow only code signed with a particular certificate to run.
Comments