Deploying sandbox solutions in Sharepoint 2010 from VS.NET

Today I was trying my hands on Sandbox solutions, which is a new feature introduced with SharePoint 2010. While going though the exercise, on how to develop and deploy sandbox solution's. I hit the wall while trying to deploy a webpart from VS.NET 2010 as sandbox solution. The webpart (a non-visual\Standard one)  which I was developing was a pretty simple one which does some basic arithmetic operations.  

If you are new to SharePoint, let me explain some some basics on what Sharepoint Sandbox solutions are all about. In a nutshell deploying solutions as sandbox-ed means

1. The solution run in a separate worker process called SPUCWorkerProcess.exe (Sandbox Worker Process) that isolates the solution from other content\apps. Running solutions in SPUCWorkerProcess.exe process means code in a given sandbox solution can only affect the site collection to which you had deployed the solution to. Usually farm level solutions are hosted in the IIS worker process (w3wp.exe) which does have access to all farm resources.
2. The solution will be deployed to Solution Gallery, instead of GAC. (GAC is the location where usually farm level solutions get deployed).
3. The solution will have only limited access to SharePoint Object Model.
4. The solution won't have access to any external resources outside the farm.
5. The solution won't have access to the disk nor execute unmanaged code. 
6. The solution won't have access to resources in a different site collection. 
7. You can deploy code from other sources(if not tested or reviewed preoperly) without fear of jeopardizing your SharePoint farm.
8. You can deploy Webparts, List Definitions or ContentTypes even without having elevated privileges like farm admin.
9. You can develop solutions for SharePoint Online (the cloud version),  then this would be the best way to deploying solutions to the cloud.

The downside with sandbox solutions especially with webparts are that, it only supports non-visual webparts i.e. you had to code all the controls in UI including layout through code, no drag  n drop. Feels intimidating?  Yes I too felt the same thing. So while going through some articles on sandbox solutions, I came to stumble upon an article, which was discussing about deploying visual webparts as sandbox solutions. Wow that's great!!! this was definitely something different from what Microsoft guys were preaching from. Reading further, the article provided a link to  Codeplex which could circumvent the problem of deploying Visual webparts as sandbox solutions to Sharepoint. As I was busy with the problem in hand, I didn't peek into that, may be I will look into that at a latter date.

Now coming back to what I was trying to resolve. My trivial nonvisual webpart was ready and the build went smoothly without errors. Now its time to be deploy my webpart to SharePoint; for that, I selected "Deploy" option from the Build menu. Boom!!! now errors started popping in, which I didn't get hold of what exactly they were. 

The initial error was "Error occurred in deployment step 'Retract Solution': Cannot start service SPUserCodeV4 on computer." Seems like some service which Sharepoint was expecting is down at the moment. After going through the windows services (services.msc), I came to find that the following service "Microsoft SharePoint Foundation User Code Service" wasn't running. I started it and changed its "Startup Type" to "Automatic". Coming back to VS.NET 2010, I issued the "Deploy" command. This time another error popped in.

This time the error was  "Error occurred in deployment step 'Activate Features': This feature cannot be activated at this time. The contents of the feature's solution requires the Solution Sandbox service to be running." Oh God, Sharepoint is expecting another service, which unfortunately is down. I started searching for this specific name "Solution Sandbox service" under windows service's, but couldn't find any exact or near by match. Next I started my search in Sharepoint Central Admin, where I navigated to "System settings" -> "Manage services on this server". Here in "Manage Services" page, lot many services were listed which did include the one I was looking for, i.e. the "Microsoft SharePoint Foundation Sandboxed Code Service".  After starting this service, I issued the "Deploy" command from VS.NET. Finally this time everything went well and the webpart got successfully deployed to Sharepoint site as  sandbox-ed solution. 


I was curious on why MSFT chaps disabled these services, which is so crucial to deploy sanbox-ed solution. While trying to unravel the reason behind this, I came across an MSDN article, which clearly mentioned the reason why it was so. The articles reads, these services were deliberately disabled on performance grounds. Starting these services will kick in three new processes, namely User Code Service (SPUCHostService.exe), Sandbox Worker Process (SPUCWorkerProcess.exe) and Sandbox Worker Process Proxy (SPUCWorkerProcessProxy.exe) which slightly affects server performance. So as to gain the performance advantage only they did disable these services.

Make sure that you DON'T stop or disable the above two services once you deploy a sandbox-ed solution to a sharepoint site as these services are crucial for the sandbox-ed solutions to function properly without which, it would fail.


You could view all sandbox-ed solution inside a site collection by navigating to(at your top level SharePoint site)  

1. Site Actions - > Site Settings 
2. Under galleries section click solutions. You should now see the Sandboxed solutions available in the solutions gallery.

Here I was talking on deploying Standard Webparts as sandboxed solutions. Sharepoint doesn't restrict itself to webparts when comming to sandboxed solutions, as you could deploy 'Event Receivers', 'Feature Receivers', 'Custom Worlflow activies' and 'Infopath Biz Logic' as well.


So the crux of using Sandbox solutions is that, you could easily port your webparts to SharePoint Cloud version (online version) with ease and moreover the site collection administrator himself\herself could deploy solutions without raising a ticket to the farm administrator.