Sand boxed Solutions in SharePoint 2010
As a developer I know my code is perfect. So good in fact I don’t need error handling and very little testing at least that’s the way I see it. Sadly I am in a minority of one especially where sys admins / it pros are concerned.
Admin’s do their best to protect and secure the I.T environments, Devs want to use the most creative and up to date technologies at their disposal often using admin privileges to do it– it’s what we like to do.
As things get more complex such as when running centralised or managed solutions the need for control over such is greater. One such environment is SharePoint online within
Office 365 provided by Microsoft. Other ISP’s are starting to offer SharePoint as a hosted or managed solution as well.
The problem they face is that they need to maintain a controlled environment and allow customers to add custom code which doesn’t bring down the server.
SharePoint provides many out of the box facilities which can be used by such clients as is, web parts, pages, sites and webs etc. Since this is all out of the box code it’s trusted.
SharePoint designer takes us a step further but doesn’t allow creation of code based solutions.
Visual Studio 2010 has made custom SharePoint code development simpler and can do things that cannot be achieved with Designer.
The drawback is that code can run amok, not mine you understand it’s everyone else’s, and so needs to be run in a controlled way or isolated.
SharePoint allows us to create such a controlled environment within which to run code. It relies on the use of a new user code process which isolates your code into a sandbox. Imagine many sandboxes (sand pits) side by side. The theory is you can do whatever you want to the sand in one box and it won’t affect the others. Throwing toys or sand from one to another is where the analogy breaks down but hopefully you get the idea.
This service shows up in the Central Administration ‘Services on Server’ list as the SharePoint Foundation Sandboxed Code service. Your code will actually run under control of another service the SPUserCodeService.
The key point here is that your code will run under the control of a sandbox service and not the usual W3WP and no matter how ill behaved it is your code won’t interfere with that in another sandbox. This in itself is of great value however when combined with Multi tenancy practical multi client hosting can be achieved see
Rational Guide to Multi Tenancy for what this technology is all about
When creating a new SharePoint project in Visual studio you make a choice as to whether you will develop a Sandbox or Farm level solution
Code developed to run in a sandbox is deployed to the Solutions gallery which you can view from the site collection settings
The gallery includes information about the resource usage. This is part of the solution monitoring support that SharePoint 2010 provides. Within central administration the number of points a sandboxed solution can use is specified in the Application management | Configure Quotas and Locks section
The points can be understood by using a powershell command as follows
Add-PSSnapin Microsoft.Sharepoint.powershell -ea 0
$measures = [Microsoft.Sharepoint.Administration.SPUserCodeService]::Local.ResourceMeasures
foreach($measure in $measures)
{
write-host $measure.name " " $Measure.ResourcesPerPoint
}
The output on my machine is
AbnormalProcessTerminationCount 1
CPUExecutionTime 200
CriticalExceptionCount 10
IdlePercentProcessorTime 100
InvocationCount 100
PercentProcessorTime 85
ProcessCPUCycles 100000000000
ProcessHandleCount 10000
ProcessIOBytes 10000000
ProcessThreadCount 10000
ProcessVirtualBytes 1000000000
SharePointDatabaseQueryCount 400
SharePointDatabaseQueryTime 20
UnhandledExceptionCount 50
UnresponsiveprocessCount 2
This shows that 10 Critical exceptions equate to 1 resource point, 50 unhandled exceptions equate to 1 resource point etc
When the resource usage is exceeded the following occurs for my Count Documents web part
Sandbox solutions give us a protected way of deploying code. Being protected, from a developers perspective, means limited.
What can we do?.
The output above was displayed on the standard team site home page using a very simple Web Part. i.e. a non visual web part. All the code is contained in the web part which can be deployed to the solutions gallery and run within the User Code Sandbox Worker process.
Other project types that can be built as sand box solutions are
- Content Types
- Site Columns
- Custom Actions
- Declarative Workflows
- List Definitions
- InfoPath forms Services without code behind
- Client Side components using Silverlight, Javascript that sue AJAX and REST
- Site pages - no code behind
- Event receivers
- Feature Receivers
I haven’t tried them all yet but intend to explore them over the coming months to see what is practical for my work and what isn’t.
As part of the control the Sandbox solution is allowed access only to a subset of the object model
The restrictions are many but that’s what you get in a protected environment. Basically you can’t access anything outside of your sandbox so no access to disk drives, databases etc. Databases can be accessed by using BCS to present them as local lists.
.
For many developers a challenge has now been set and their time will be spent looking for ways to break out of the sand box. For those who prefer the approved approach full trust proxies can be developed which allow access to otherwise protected resources. In essence you build a tunnel out of the sandbox.
Administrative Control
Administrators can block solutions by using the central Admin Sand Box Solution management
Where they can block a solution and provide a meaningful message to the end user
When the page is now run the message is displayed
Summary
The sandboxed environment is a compelling way ahead for developers who want to deploy their solutions within online versions of SharePoint. I am thinking of a future version of the Solutions Gallery which is more like an App Store. This fits neatly in with the concept of feature packs found in SharePoint multi tenancy which is the infrastructural side of using SharePoint as a common but isolated platform for providing services to independent customers or departments.
The building blocks are their now and I would guess that greater levels of control will be developed in future SharePoint versions that allow service providers to partition SharePoint server farms using graphical tools and distribute or block applications in an easy and intuitive way something like the disk partition manager found in windows. With a bit of thought Developers can keep being creative and administrators secure and they can collaborate nicely together which is what SharePoint is all about J
