Few things to remember While Developing Sandboxed solutions


SharePoint 2010 provides a great new feature called “Sandboxed Solutions” which separates the User Code Host Process from IIS Worker Process and let the Site Collection Administrator deploy the solution easily from Solution Gallery without direct intervention or concern of Farm Administrator and thus it does not affect the application pool while maintaining stability across the Farm. But, Sandboxed Solution has got some limitations that we should remember:

1. You cannot develop any Visual Web Part, Application pages etc. as Sandboxed Solutions which requires direct access to 14 hive.

2. You cannot use any code which requires elevated privileges. For example: SPSecurity object is not supported in Sandboxed Solution. Often we are used to use SPSecurity.RunWithElevatedPriveleges which runs the segment of code as a system account which is not supported at all in Sandboxed Solution. Although, it will not throw any validation error while building the solution from Visual Studio 2010, it will eventually throw an error saying “Failied to load assembly” while running the feature which tries to execute SPSecurity object after deployment.

3. You cannot access another site collection as Sandboxed Solution restricts you only to Current Site Collection.

4. Normal Debugging method from Visual Studio 2010 will not work for Sandboxed Solution if you have already deployed it. You can debug it in normal way by pressing “F5” before deploying though. In order to debug an already Deployed Sandboxed Solution, you need to attach to Sandboxed Worker Process “SPUCWorkerProcess.exe” manually because it does not run under the IIS Worker Process used by SharePoint also known as w3wp.exe.

Leave a comment