Time to play in the sand with your SharePoint 2010 solutions

November 11, 2011 at 6:46 pm | Posted in Microsoft, Technical Tips | Leave a comment
Tags:

A friend of mine, Dave, had a roommate while he was in college. Things were fine between the two of them until the roommate started dating a fairly unstable girl; she  made Dave’s life so unpleasant that he decided to move out.  In SharePoint 2010, there is nothing that will help you with a roommate’s crazy girlfriend. However, SharePoint 2010 can prevent custom code from destabilizing your farm and making your life a mess through the use of a sandboxed solution.

When site collection users upload their own custom code solutions to a sandbox, the custom code solution cannot jeopardize the stability of your farm (or steal your roommate’s CDs). Sandboxed solutions are stored in a solution gallery. A sandboxed solution can be used to run an application in a secure, monitored process that has access to a limited part of the Web farm, mitigating the impact of untested or potentially unstable code on the rest of the farm.  You can measure memory consumption,  CPU execution time, and database query time.  You can monitor the process and check for anomalies, such as abnormal termination, unhandled exceptions, and critical exceptions.

The structure of a sandboxed solution is very similar to a farm solution, which generally runs with full-trust permissions. The main differences lie in how a sandboxed solution is deployed and in which process hosts the solution. Typically, a farm solution runs like any ASP.NET application in the IIS worker process called w3wp.exe. A sandboxed solution, on the other hand, runs in a sandboxed worker process called SPUCWorkerProcess.exe. When a request to access a sandbox solution occurs, the SharePoint execution manager that is running in the IIS worker process seeks out a sandbox worker process for the sandboxed solution to run in.

The SPUCWorkerProcess.exe process can have separate quotas placed on it to protect the farm from sandboxed solutions that perform harmful activities, such as producing memory leaks. This means that the same sandboxed solution can run with full trust when it’s deployed at the farm level, and with partial trust when it’s deployed at the site collection level.

Monitoring metrics

Sandboxed solutions are a great way to deploy third-party Web parts without fear. A package deployed as a sandboxed solution will run as an isolated and monitored process. It’s vital to monitor the solution’s metrics, especially if you plan to deploy it farm-wide at a later time. When you collect metrics on the sandboxed solution, they’re compiled by the timer job.  You will have to monitor the sandboxed solution for a few days to find the correct quotas to set. For example, you could set the Sandboxed Solutions Resource Quota limits to the default values. If, for example, you later notice that the Web Part displayed data more than 6,000 times in a 24 hour period over the past two weeks, then you should increase the Limit maximum usage per day to: value to 500 points. When the total resource points used exceeds the daily limit of the Sandboxed Solutions Resource Quota, the sandbox is turned off for the entire site collection.

For another example, suppose a Web Part performed a SharePoint database query and displayed data more than 6,000 times in a 24-hour period. This means that the SharePointDatabaseQueryCount resource ran more than 6,000 times. Every time the SharePointDatabaseQueryCount resource runs 20 times, the site collection uses 1 point. When the SharePointDatabaseQueryCount resource runs more than 6,000 times and any other resources reach their Resource per Point total, the Sandboxed Solutions Resource Quota of 300 will be exceeded, and the solution will not function until a timer job resets it. If this is occurring for your solution, then you could eliminate the problem by increasing the point total on the Sandboxed Solutions Resource Quota to at least 500 points.

Sandboxing limitations

Sandboxed solutions support List definitions, List instances, Workflows, Navigation, Custom Workflow Actions, and most other SharePoint item types. However, sandboxed solutions do have some limitations. Nothing can be deployed to the file system of the servers from a sandboxed solution.  Certain files such as Application pages, user controls (.ascx files), and localization resource (.resx) cannot be deployed with a sandboxed solution. You cannot deploy site definitions in a sandbox solution. Images, script files, and Features in sandboxed solutions are not deployed to the file system of the front-end server, but rather to the content database. Features deployed in a sandbox solution cannot span the site collection or Web site, since a sandboxed solution is not allowed to access anything outside the site collection where it is deployed.

Life is tough enough. Make sure that you test any custom solutions or third party solutions by sandboxing them.

For more information on sandboxing your SharePoint 2010 solutions, here’s a rundown of handy references:

MSDN Library: What’s New: Sandboxed Solutions

MSDN Library: New Developer Content for SharePoint Foundation 2010 

MSDN Library: Sandboxed Solutions Architecture in SharePoint 2010

MSDN Library: Restrictions on Sandboxed Solutions in SharePoint 2010

Happy sandboxing!

–George Monsalvatge

Leave a Comment »

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Blog at WordPress.com.
Entries and comments feeds.

%d bloggers like this: