Sandbox Solutions – SharePoint 2010

You must have come to this post searching for ‘Sandbox Solutions’ in one of your favorite search engines. Good that you are at the right place to know in and out of Sandbox solutions.

Why do I need a Sandbox Solution?

Scenario 1# Sometimes I am a dumb programmer.
Programming is like hand writing. The start is the most important. The better the writing habbits are, the better your wrting style is.  Even for a programmer, if good coding habits are not adopted/exercised right from the beginning, he would some how mange to get the stuff working, but he will never realise that its not he best way to do. Especially with SharePoint even after taking a great care in disposing SharePoint objects there might be  chances of bad coding practices to creep in, leaving some objects undisposed which can potentially throttle the server with high memory usage.

You might be thinking of asking me why is Garbage Collector not taking care of this? For instance, when using objects of type ‘SPSite’ or ‘SPWebapplication’, part of the actions do not run under managed code at all. You shouldn’t be surprised to know that CRUD(create, read, update, delete) operations to ‘content’ database are performed by a COM component which does not run managed code and the ‘Garbage Collector’ is not even aware of these objects. This is one reason why you have to dispose your SharePoint objects promptly. To handle situations like this  ‘Sandbox Solution’ is the answer.

Scenario 2# I hate my administrator
As a developer, once you finish your development and have your solution package ready you are eager to deploy it to staging or production. Its not very uncommon to hear from your administrator asking you to come back. You will be pissed off even more if you are a site collection administration and not able to deploy your own solutions to your site with out administrator’s intervention. ‘Sandbox Solution’ is the answer.

Scenario 3# I hate my developer
As an admin, I really get scared when my developers approach and say “The solution package is ready. Can you please deploy that to production?” At that moment, I have so many things going on in my mind. Will his solution get my portal down? I am not sure what his code does, Will it delete all my existing webapplications? Is his code accessing local file system and exposing sensitive data?  Even if I have tools like SPDispose check tool that can check memory leaks, there are very low or no chances of validating his code against any bad practices. ‘Sandbox Solution’ is the answer.

Scenario 4# My client always has a big NO!
For instance consider yourself as a service provider or a product development company. When the clients buy our product/SharePoint solution, what is the guarantee that you don’t have malicious code with in your solution that could access their local files or sensitive data? How can they trust that your code is not consuming too much of their server resources? There might be a situation where the client might not even let you change their folder/file structure, which in many cases the developer becomes handicapped with out being able to change webconfig, or add files to 14/12 hive. ‘Sandbox Solution’ is the answer.

Fortunately to handle situations like above, Microsoft has introduced ‘Sandbox Solutions’. So what is a Solution? Typically development is like solving a puzzle, when you finished solving and got the peices together, its time to pack or wrap it up. So you develop and pack all your folders, files together in file with .wsp extension as a solution to your client’s requirements. So your client has SharePoint installed and needs to deploy this solution in their farm. Once deployed, all these files get into those folders that were created while installing SharePoint. SharePoint picks these up when the end user requests for them via the application built. Contine reading to understand the concept of solution packaging and how ‘Sandbox Solutions’  provide solutions to the above mentioned scenarios….