Business users, power users, information workers, and developers – they all want to deploy their solution easily and quickly to their sites in SharePoint without the burden of asking and waiting for the IT departments. On the other side, the IT folks want to sleep well at night and avoid phone calls at 5AM because some new component made the company portal to crash. Sandboxed solutions are here to address this conflict, to be easily installed by site collection owner and to run under restrictive model which minimizes the risk of creating damage. That’s also why sandboxed solutions are the only way to deploy code into SharePoint in the cloud (SharePoint online, Office 365). This article outlines the core principles, capabilities and limitations of sandboxed solutions that a SharePoint developer should know.
Who are they?
SharePoint online is a product from Microsoft which brings SharePoint to the cloud, simply put, it delivers SharePoint as a hosted service and enable users to enjoy SharePoint’s features and platform on the internet without the need to install and maintain locally (On-Premise). Upon subscription one receives private SharePoint site collections in which he can do all those things we do on a “Normal” SharePoint installation (Create sites, design web pages, author workflows, manage documents, manages lists of information, and so on and so forth).
Sandboxed solution is a technology within SharePoint 2010, which enables to create code solutions that are throttled and executed with low privileges but can be deployed easily and directly to site collection, even to site collection in SharePoint online. Just like mobile phone application (think Google Market or apple AppStore), these solutions can be installed easily by non-technical users..
Sandboxed solutions are the only way to develop code solution for the cloud (SharePoint online). Farm-solutions (the plain .WSP files you know from the past) are forbidden in the cloud. However, Sandboxed solutions are important concept also for local SharePoint installation (On-Premise), because they allow Site collection administrator to deploy code solutions independently, without the intervention of a farm administrator. Rationally, with the freedom to deploy code without any IT guy around directly from within the SharePoint site – some limitations must be set to protect the environment.
Limitations: What can we develop for SharePoint online?
The main concept here is: ‘Mind your own businesses’. As long as you deal with your dedicated site collection – you are good. Whenever you try to dig around, query other sites, contact other systems around – expect walls and dragons. The motif here is obvious, your site collection lives together with other customers’ sites in the same server. On your local On-premise SharePoint if one component makes a site crash – The damage spans only within the same company. You can settle this incident over lunch in the companies’ cafeteria. However, in SharePoint online, without the subject limitations, the code of various companies run together within the same server, North-Korean company component might crash South-Korean Company’s web site if they lives within the same server. Imagine the consequences.
So with SharePoint Online, as a site collection administrator, you can do almost all the things like in “regular” SharePoint, for example: Create sub-sites, manage security groups, craft forms, customize master pages, design layout and web part pages, edit CSS files, author workflows, customize the ribbon, change list views – almost everything on the site collection level and below. Similarly to the experience of “regular” SharePoint development you can use browser or SharePoint designer for all those customizations.
However, everything which is above the scope of your site collection – is restricted. No central admin, no web applications management, most of the service applications are not available and access to the server file system is forbidden. As an exception to that, following is a list of service applications that are still available for management: User profile service, Forms services and the Managed metadata service. Besides those services all other services are out of bounds. This limitation might be significant for some development, for example if want to grab some data from external system using BCS (external content type) – this can’t be done since BCS is a service application.
Although a little bit simplistic and not precise, SharePoint online capabilities can be summarized with the following:
SharePoint Online capabilities = almost everything on the site collection level and below + user profile management + form services management + managed
Describe Sandboxed solutions in a brief
As inferred from the previous section regarding SharePoint online, cloud solutions and some On-Premise solutions should keep the following rule: (1) Be discrete – avoid from digging outside the boundaries of the site/application since other neighbors live around on the same server (2) Avoid being greedy – consume reasonable amount of resources since all the neighbors use the same server resources (3) Allow quick and easy installation without the intervention of farm administrators. That is exactly the motif behind Sandboxed solution technology – to provide code components which are under control in the context of access and resource consuming but can be deployed quickly and easily.
Sandboxed solutions looks similar to typical SharePoint solution, they are also .WSP file, they too being developed using Visual Studio 2010 but with two remarkable different:
1. Sandboxed solution can be installed from within the site-collection settings using the browser only by uploading a .wsp file to solutions gallery on the site collection. No farm administrator is required, no STSADM or powershell, just like master pages or site templates they live within a site library.
2. On run time, components of the sandboxed solution run in a dedicated, isolated and restricted process. As long as you conform to the limitations, many artifacts might be developed using sandboxed solution, to name a few: List definition, Content type, Web Part , Web template (the step brother of site definition), workflow activity, master page, layout page, custom action (although not action groups), List instance and more. All of the above can be packed for a site on the cloud (or On-Premise) as a Sandboxed solution.
Development of sandboxed solutions are almost the same like “regular” solutions: you start by creating a new project in VS 2010, if the project type is eligible to be a sandboxed solution you’ll be prompt whether you like to set this project as farm or sandboxed solution, the development process is exactly the same (remember not to violate the restrictions) and just like any other SharePoint development a .WSP file is generated in the end. This WSP file can now be uploaded to the solutions gallery in the site collection.
Note that if your code contains restricted operations (for example calling to objects in the object model which are outside the site collection level) – you won’t get any compilation error, this will be discovered when you’ll try to activate the solution in the solution gallery. That is why you are advised to download the Visual Studio power tools for SharePoint 2010 – this tool provides templates for sandboxed projects, compilation errors for sandboxed solutions and more.
Explain the limitations of Sandboxed solutions
All the limitations are concerned with forcing the code to deal only with objects and data from within the site collection where the solution was deployed to and keeping the code from consuming too many resources. Though simplistic, these limitation can be divided into two groups: SharePoint limitations and .NET limitations.
1. Sandboxed solution code can access only subset of the object model, as a rule of thumb, only objects on the site collection level (SPSite) and below are permitted. SPView, SPWeb, SPList are all examples of classes which sandboxed code can access, however if you try to access SPWebApplication, SPFarm, SPJobDefinition or other objects which are outside the site collection scope – an exception will be thrown.
2. Resource throttling – Sharepoint collects information about the resources which are consumed by each single sandboxed
solution and all the solutions in the site together. If single request exceeds the allowed resources – it’s terminated immediately. If single solution violates the resources threshold– it’s terminated. If all sandboxed solution together exceed the allowed daily usage– all sandboxed solutions are subject to abortion until the next day. SharePoint calculate the resource consumption by using 14 metrics which are calculated continuously (for example: CPU time, content DB queries, number of exceptions, etc.), each metric is assigned a “resource points” definition, for example if the metric “UnhandledExceptionCount
= 50 resources per points”, after 50 invocations with unhandled exceptions – the site collection would have been used 1 resource points. The default daily threshold is 300 resource points. Additionally, each request has a time threshold (by default 30 seconds) – each request which is running for more than 30 second will be terminated.
3. Code is not allowed to be impersonated – run with elevated privileges (spsecurity.runwithelevatedprivileges).
4. Web part connection is not allowed –at first, this one sounds odd but it actually clever limitation because otherwise one can use non-sandboxed web part to consume external data and pass to sandboxed web part via connection.
5. The above lists only the major limitations, please read the documentation for the entire list.
1. Sandboxed solutions run in their own dedicated process (SPUCWorkerProcess.exe), they have dedicated code access security assertions (CAS) and actually also a different version of SharePoint DLL (this is how the limitations in the previous paragraph are achieved). One of the derived limitation, is that sandboxed code can only call .net components which are annotated with “AllowPartiallyTrustedCallers” attributes and are located in the GAC, this blocks around two-third of the .net 3.5 API (!), for complete list of allowed and blocked libraries click here.
2. No access to the local disc. This implies that all the following common activities are none-relevant in sandboxed code : ULS Logging, deploy artifacts to the ~14 directory, application pages, resource files (!) , site definition (!) , user controls. All these are not available in sandboxed solutions.
3. No network calls are allowed, neither database direct access nor web services (even not using BCS).
4.The above lists only the major limitations, please read the documentation for the entire list.
Overcoming Sandboxed limitation
Should the need arise and you’ll need to overcome one of the aforementioned limitations in your sandboxed solution, there are some techniques you may employ:
- Apply the “hybrid approach” (not feasible for SharePoint online) – start by developing the restricted operation in your own .net component, package the code in a plain SharePoint solution, (farm solution), for example, make a query against a SQL server or make your code write to the file system), make sure your code inherits from “SPProxyOperation”, also make sure that the DLL is deployed to the GAC and that’s all. Now your component can be called from a sandboxed code. This approach require the permission to deploy farm solution (besides the sandboxed solution) and that it the reason why it can’t be done in SharePoint online.