Saturday, June 26, 2010

Sharepoint 2010 Sandbox solutions

I would like to highlight about sandbox solutions available in sharepoint 2010.

Sandbox solutions are  a way where sharepoint solutions can be deplyod in safe envirenments. When we create a WSP package in sharepoint 2007, generally we are creating a batch file for using STSADM tool in order to install WSP package to farm. And those are full trust solutions. While sandbox solutions can directly be uploaded to site collection level using access rights of site collection administrator. It doesnt requires Farm server administrator.

Sandbox solutions are limited to site collection only. They are being stored @ solution gallary of top level site collection.

SPUCWorkerprocess.exe

Sandbox solutions are loaded into a separate process (SPUCWorkerProcess.exe). This process is monitored and implements quotas and throttling to protect the farm from sandboxed solutions that perform harmful activities, such as running tight loops that consume CPU cycles.

FOR DEVELOPERS: in oder to debug sharepoint solutions you need to attach your visual studio solution to this process.

Capabilities of Sandbox Solutions

  • List Definitions
  • List Instances 
  • Onet.xml
  • WebTemplate feature elements (instead of Webtemp.xml) 
  • Content Types/Fields 
  • Navigation 
  • Module/files 
  • Feature callouts 
  • Web Parts 
  • Support for all Web Parts that derive from System.Web.UI.WebControls.WebParts.WebPart 
  • Event receivers 
  • SPItemEventReceiver 
  • SPListEventReceiver 
  • SPWebEventReceiver 
  • Custom actions 
  • Declarative workflows

What Sandbox solutions are not supporting
  • Visual Web Parts  
  • Application Pages 
  • Custom Action Group 
  • HideCustomAction element 
  • Content Type Binding 
  • Web Application-scoped features 
  • Farm-scoped features 
  • Workflows with code




Advantages of Sandbox Solutions

  • Solutions can be installed directly by site collection administrators, no need for farm administrator. (NOTE: DONT FORGET TO ACTIVATE SOLUTION AFTER UPLOADING)
  • No need to deploy from server. No server reset required (what? no IISReset??? :) ), what else a developer required!!!!
  • Testing could be achieved from test site collection itself @production server.

Limitations of Sandbox solutions
  • Not all kind of code will be permitted in sandbox solutions. (cannot create site collections, cannot create visual webparts, can not do any IO operations)
  • There is a special environment to execute sandbox solutions. Separate storage of the solution files, separate process that runs its code and separate memory to go with it.  This will increase overhead when there are plenty of sandbox solutions. If you have deployed same solution on multiple site collections and in case when u want to upgrade that solution, it needs to be done one by one.
  • Have to remove, re-add and re-configure web parts when switching between deployment methods of same solution
  • Cannot use Page.ClientScript to register scripts
  • No support to Microsoft.SharePoint.WebPartPages namespace.
  • Making web service calls over the internet, or accessing code that is not marked to allow partially trusted callers are not supported. You also can’t deploy files to disk or add assemblies to the GAC in a sandboxed solution, and security-related functionality, such as running RunWithElevatedPriviledges and other SPSecurity methods, is not allowed.
  • No support to SPUtility.SendEmail namespace for sending mails.

 Examples

  1. http://msdn.microsoft.com/en-us/magazine/ee335711.aspx
  2. http://sandbox.codeplex.com/

Related posts

1 comment:

  1. Good article , since i was searching the article for sandbox. this article helped me to understand the sandbox solution.

    Thanks Nitin

    ReplyDelete