Home > SharePoint 2010 > Sandboxed Solutions in SharePoint 2010

Sandboxed Solutions in SharePoint 2010

December 14th, 2009

SharePoint 2010 came with lots of new features and ways for developers and users. Sandboxed solution is one new way of deploying solutions. You can also have the solutions as you have in SharePoint 2007, but those solutions will be called farm solutions. Sandboxed solution is per site collection. Sandboxed solution’s deployment is different than normal solutions. Every site collection in SharePoint 2010 has a library for sandbox solutions. You simply need to upload your solution (wsp) to this library. And then activate the solution. So no server reset is required.
Sandboxed solution doesn’t make server reset, so you can do as much deployments as you want. It is very convenient from developer’s point of view. But at the same time there are some limitations for sandboxed solutions. Farm solutions run with full trust, whereas sandbox solutions mark as partially trusted solution. The major difference is the way of deployment. You can run the same solution under full-trust, but then you need to deploy it as a farm solution. As you do in SharePoint 2007.
The limitations for the sandboxed solution is due to the factor that it should not be a performance hinder for farm and application. These are the major limitations I found so far in sandboxed solutions.

  • You cannot run your code with elevated permissions in sandboxed solution
  • You cannot use Visual web part template for sandboxed solution. Because sandbox solution cannot deploy files to web front end.
  • You cannot access internet to make web service calls directly
  • You cannot access hard drive to read/write files
  • you can’t access code that is not marked to allow partially trusted callers
  • you cannot deploy assemblies to GAC

It seems that in sandboxed solutions’ you cannot do much but still you can. In sandbox solution you can access all the classes under SPSite, SPWeb, SPList, and SPListItem. You can create Web Parts, list definitions and instances, content types and fields, modules, declarative workflows, and event receivers. You can read and write to lists and libraries within same site collection. Sandboxed solutions provide enough functionality to build most of the applications. The best thing is rapid deployment and no server reset.
Being a developer you would definitely want to go out of the limited scope of sandboxed solutions, like communicate with a database or web service. According to SharePoint team the best way to reach out of the sandbox is by using the Business Connectivity Services (BCS) to create an external content type. You can then read and write to the data source from the sandboxed solution. Another, more advanced, way to reach outside the sandbox is to create a class that runs in a full-trust process outside the sandboxed worker process to proxy calls. This proxy class is deployed as a farm solution and is callable from the sandboxed solution.
Sandboxed solution runs under a different process, farm solutions run under IIS worker process (w3wp.exe). But sandboxed solution runs under the sandbox worker process SPUCWorkerProcess.exe.
In sandboxed solutions library, you can activate and deactivate solutions. You can also remove solution from the library, but solution should be in deactivated state. You can also upgrade a sandboxed solution. To upgrade a solution, you need to create a .wsp file that has a new file name but the same solution ID. The easiest way is to use Visual Studio 2010 for it. Open the same solution and after the changes, give the package a new name using package designer. When you try to upload new solution, it will detect the solution with same id and ask for upgrade. After you upgrade, you will see it activated new version and deactivated old solution.

Sandboxed solution is a great enhancement for developers and also for administrators. Now all the solutions deployment is not the responsibility of the farm administrators. Site collection administrator can deploy, manage and monitor sandboxed solutions for their site collections. Developers can test functionality without disturbing the whole farm. They can deploy the same solution with full trust later, when they have confidence in the new functionality or at convenient time. Isn’t that a great news.

Cheers

  1. September 3rd, 2010 at 14:44 | #1

    Me and my friend were arguing about an issue similar to this! Now I know that I was right. lol! Thanks for the information you post.

  2. September 4th, 2010 at 04:27 | #2

    Very Interesting!
    Thank You!

Comments are closed.