SharePoint 2010 Sandbox solution 1 – Overview of Sandboxed solution

Please note that I have posted this blog orginally on http://aspe-it.com/blog/2013/sharepoint-2010-sandbox-solution-1-overview-of-sandboxed-solution/

SharePoint aims at reducing the involvement of IT team in solution lifecycle. Deployment and monitoring of custom solution is one area where Farm administrators (IT team) are still putting lots of their efforts. This effort can be reduced (I would use the word REDUCED effort instead of no effort because of the concept of Solution Validation) if the business needs can be fulfilled by Sandboxed solution.

In this series of blogs, I’ll be covering following topics in each block

1.       Overview of Sandboxed solution

2.       Architecture and Execution Model of Sandboxed solution

3.       Sandbox Proxy

4.       Solution Validation

Overview of Sandboxed solution

If I try to define sandboxed solution technically then the easiest way is — It runs under context of SPUCWorkerProcess (instead of w3wp) which has limited access to the resources

Before you decide on Sandboxed solution for your application, you need to be aware of the following

1.       It has access to only a subset of SharePoint object model. So limited operations can be performed

2.       It has no access to file system. So you cannot create Visual Web Parts or read/ write web.config file or log exceptions into log files

3.       No support to external web services

4.       No Email support using SPUtility.SendMail

5.       Impersonation is not allowed. So you cannot use SPSecurity.RunWithElevatedPrivileges

6.       Scope of the solution is limited. You can access only site collection level resources in which it is deployed

7.       Performance is another concern. If sand box worker process runs for more than 30 seconds then the UserCodeHosting service terminates the process

Oh my god! There are so many restrictions.

Don’t worry there are ways to perform full trust operation even after these restriction. I’ll show it in further blogs (3. Sandbox Proxy)

Now we are aware of, on high level, what we can’t do. Let’s see what we can do. We can create

1.       Web Parts (normal, not visual web part)

2.       Lists

3.       List Templates

4.       Custom Actions

5.       Event Receivers

6.       Content Types

7.       Site Columns

8.       Workflows

9.       Event Receivers

And many more…

 

Now we’ll look at the lifecycle of a Sandboxed solution at a very high level (as I’ll be diving deep in subsequent episodes)

 

1.       Deployment – The Site Collection Administrator (SCA) gets a solution as wsp file and uploads it into Solution Gallery. Once it is uploaded she needs to activate it. On activation the solution is validated against validation logic (either OOB or custom). IIS reset/ Web App pool recycling required. Great huh?

2.       Activation – If the validation is passed then the solution is activated which activates all the features contained in the solution. The SCA doesn’t need to activate the features separately(But cross checking is always good :P). If we assume that a feature contains a web part then on activation the web part would be populated into web part gallery

3.       Deactivation – On deactivating the solution, the web part no longer executes but still be present in the web part gallery

4.       Deletion – The solution is deleted. The web part, obviously, doesn’t executes but still it remains in the web part gallery

By now you would be aware of WHAT IS SANDBOXED SOLUTION, WHAT WE CAN AND CAN’T and LIFE CYCLE OF SANNDBOXED SOLUTION. Here I am concluding this episode of Sandboxed solutions and will take up Architecture and Execution model next