@jthake, @sahilmalik and @givenscj did a podcast on Sandboxed solutions, go take a listen!
Sandboxed solutions also offer a way to build SharePoint Web Parts and deploy them to a site without needing administrative intervention---that is, you can deploy a Web Part to a SharePoint site and have it run in the context of that site either in an on-premises instance of SharePoint or in the cloud using the hosted version of SharePoint.
Some of the key takeways from the session at #SPC09 were that Sandboxed Solutions are the preferred approach for all WSP deployment scenarios. The only reason NOT to use them is where it doesn't support what you are doing.
"Any solution that is created for Sandbox can be deployed into a special Solutions Gallery in the site-collection called SOLUTIONS GALLERY. And all these solutions that are deployed here can be activated from a menu (ECB menu) on that solutions gallery itself, hover around the item and you will get a ACTIVATE/DEACTIVATE menu. For all this to work properly we have to make sure that the "Microsoft SharePoint Foundation User Code Service" is starting on one or more of the servers in the Farm. You can confirm whether the service is running or not by checking the sandbox resource quota that is available on the top of the same page (Solutions Gallery Page). All of the resource assignment and monitoring for the Sandboxed solution can be controlled from Central Admin app.
Sandboxed Solutions to work need these 3 thing:
- User Code Service (SPUCHostService.exe): this service will decide whether the box on which this service is running will participate in the Sandboxed solutions are not. This should run either on one box or more for sandbox solutions to take advantage of the server and run it on that server.
- Sandbox Worker Process (SPUCWorkerProcess.exe): This is the actual process in which the Sandboxed Solutions run.
- Sandbox Worker Process Proxy (SPUCWorkerProcessProxy.exe): If you have already studied and are aware of the new Service Application architecture then you get this one, this is the proxy which the web-app will use form the proxy group to use the sandbox."
INTRO: Sandboxed Solutions in SP2010
10 reasons to use Sandboxed Solutions
- Sandboxed solutions are secure.
- Sandboxed solutions can be monitored.
- Sandboxed solutions do not affect other sandboxed solutions, well atleast not in other site collections is what I mean.
- Sandboxed solutions do not touch the file system for the most part
- Sandboxed solutions skip application pool recycles, so debugging is not such a pain.
- Sandboxed solutions allow the site collection administrator to perform deployment and upgrades
- Sandboxed solutions make CAS policies look like the out of style hairstyles of 1980s
- The Solution validation framework for sandboxed solutions is exntensible, simply inherit from the SPSolutionValidator base class.
- Sandboxed solutions remove the need for line by line code reviews
- Sandboxed solutions allow you to offer different level of SLAs to different site collections using Resource Quotas.
Source: Sahil Malik
What is supported by sandboxed solutions?
Basically it is a narrowed down subset of the SharePoint OM. This is controlled with VS2010 by selecting your Visual Studio project as a sandboxed solution. It will hide any methods/classes that are not available automatically.
The following capabilities and elements are available in sandboxed solutions:
- List definitions
- List instances
- WebTemplate Feature element instead of Webtemp.xml
- Content Types/Fields
- Feature callouts
- Web Parts derived from WebPart
- Event receivers
- Custom Actions
What is not supported by sandboxed solutions?
The following capabilities and elements are not available in sandboxed solutions (from MSDN):
- Custom Action groups
- HideCustomAction element
- Content Type Binding
- Web Application-scoped Features
- Farm-scoped Features
- CustomPropertyToolPart Class
(not on MSDN)
- programmatic workflow
- Event receivers
- timer jobs
- visual WebParts
- SharePoint mapped folders (e.g. "_layouts", and "images")
The following .NET namespaces are not supported by sandboxed solutions:
Administrators can monitor a solution and set a quota for how many "resource points" it can use in a day. There are various measures that build up points for a solution.
[System.Reflection.Assembly]::Load("Microsoft.SharePoint, Version=22.214.171.124, Culture=neutral, PublicKeyToken=71e9bce111e9429c")
$s.ResourceMeasures \| Select-Object Name,ResourcePerPoint
The default quota is 300 resource points a day, if you exceed that your solution is "cut off". The below table shows how many instances of a resource measure it takes to build a resource point e.g. 1 "AbnormalProcessTerminationCount" is one resource point, so 300 of these would "cut off" the solution.
|| Resource Per Point
Allow custom validation of a solution, installed at the farm scopeInstalled in a FeatureActivated eventOnce deployed, when you attempt to deploy a solution that breaks a validation rule, an error is displayed.