As a non-developer, I’m unfamiliar with the new sandbox capabilities of SharePoint 2010, so I attended Maurice Prather’s SPTechCon session on the topic to gain an understanding of these capabilities. As described Maurice, sandbox solutions are used to:
- Effectively delegate installation of solutions to site collection administrators
- Safeguard and improve the stability of Web servers
- Securely provide customizations
- Reduce time to deploy solutions
- Provide a relief valve in corporate and hosted environments
- Give developers the opportunity to maximize their XML skill set
The sandbox is one of the managed services on the server, and is the only service that can be turned on at any SharePoint server. It will, however, be turned off default, and you can only manage the sandbox through PowerShell.
The value of the sandbox to the developer is that it is scoped to the site collection and down. You won’t have administrators’ interference, and you are able to offload deployment of sandbox solutions to site collection owners. The value to the administrator is that changes are isolated to site collections only, and you can monitor the use (as it will consume resource points).
With the sandbox, the file system is off limits and the database is useable. Maurice mentioned the pain of the “old days” when you had to use Code Access Security (CAS) to secure individual assemblies. CAS is now set on a per-process basis, which means that all assemblies have the same policy, making it easier to debug and maintain. Silverlight follows this same structure.
My favorite feature of the sandbox features that Maurice demonstrated is the ability to set full trust proxies. They can be used to expose certain operations, but Maurice noted that they are deployed farm-wide, so everyone has access. It’s more like enabling a library, not necessarily turning on a feature. Maurice also covered how to work within the sandbox limitations, noting that when using external content types through BCS they cannot directly interact, but can interact if the data is presented as an external list. Maurice also cautioned that custom workflow activities can’t be used within the sandbox unless the custom actions have been published out.
I also learned a bit about monitoring, system performance, and setting quotas. There is value in the sandbox being a different thread so that it has the opportunity to be monitored; each system is regulated against the quotas to protect the site collection, and quotas specify limits for resource consumption per day.
By default, the sandbox has 300 points. Maurice mentioned that since this is a brand new feature, no one knows what the “right” number should be, so be sure to monitor your usage. If quota is exceeded, the sandbox will stop working until the values are automatically reset at midnight.
The session got a bit too technical for me in parts, but the general knowledge I gained about the sandbox has certainly added to my appreciation of the power and flexibility of SharePoint.
Bamboo Nation’s complete coverage of SPTechCon Boston 2010: