Top 10 things to consider when writing SandBoxed Solutions

Posted on 11/24/2009 @ 9:06 PM in #SharePoint by | Feedback | 3274 views

In sequence to my previous blogpost about Top 10 reasons to use Sandboxed solutions, here are my top 10 things to consider when writing Sandboxed solutions.

  1. Memorize this list - ContentType, Field, CustomAction, Module, ListInstance, ListTemplate, Receivers, WebTemplate, WorkflowAssociation, PropertyBag, WorkflowActions. This is what the elements.xml of a sandboxed solution can do. If you try and architect your solution that fits within the above, your SharePoint farm will treat you well.
  2. SandBoxed solutions don’t run in W3Wp.exe. They run in SPUCWorkerProcess.exe (UC = User Code, SandBoxed solutions were at one point called user solutions). Thus while Sandboxed Solutions are isolated by default, you can and should get further level isolation by running your sandboxed solutions on a dedicated server(s).
  3. SPUCWorkerProcess.exe will prevent you from accessing anything outside the site collection where the solution has been deployed. Bye bye making web service calls over the internet, or accessing code that is not marked to allow partially trusted callers. 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.
  4. In #3, I lied about not being able to deploy stuff to GAC. WebParts that are sandboxed solutions do deploy the DLL to GAC.
  5. There is nothing fundamentally different between a sandboxed solution and a farm solution – except how it is deployed, and what they may contain and do. Thus, you could deploy a Farm solution as a sandboxed solution, but it’ll just blow when it tries to do anything funky. You can and should prevent the uploading of sandboxed solution, that is not really a sandboxed solution using a custom SPSolutionValidator (codeplex project anyone??)
  6. Regarding #3 and #4, if a sandboxed solution contains an assembly, only the site collection administrator can deploy it. However, if a sandboxed solution does not contain an assembly, anyone with full control on your site can deploy it.
  7. Sandboxed solutions don’t write anything to the SharePointRoot (Previously known as the HIVE). But if you deploy a sandboxed solution as a farm solution, it will create a directory in template/features/<yourfeaturename>.xml for instance. Remember #5 – there is nothing fundamentally different between a sandboxed solution and a farm level solution .. just what they contain, what they can do, and how they are deployed.
  8. Regarding #3 – things that Sandboxed solutions cannot do – if they NEED TO do those things, you should write a proxy class that runs in full trust outside the sandboxed worker process. This proxy has to be deployed as a farm level solution, but can be called by other sandboxed solutions.
  9. Sandboxed solutions can be monitored using the Site Quota page at /_admin/siteQuota.aspx in your central admin. Monitoring is done on a point level system – if your solution exceeds a certain # of configurable points (by default 300), all sandboxed solutions within the site collection stop working for 24 hrs, or until the timer job resets. The following metrics can contribute to this “point-calculation”, and thus the following things on a sandboxed solution can be monitored-
    • AbnormalProcessTerminationCount
    • CPUExecutionTime
    • CriticalExceptionCount
    • InvocationCount
    • PercentProcessorTime
    • ProcessCPUCycles
    • ProcessHandleCount
    • ProcessIOBytes
    • ProcessThreadCount
    • ProcessVirtualBytes
    • SharePointDatabaseQueryCount
    • SharePointDatabaseQueryTime
    • UnhandledExceptionCount
    • UnresponsiveprocessCount
  10. If you can achieve a functionality using SandBoxed solution, but you insist on delivering that functionality as a Farm Solution, and you have no needs to backport to SP2007, I will personally come and interrogate you on your reasons for doing so.

Sound off but keep it civil:

Older comments..


On 11/25/2009 2:43:23 AM SPNewbie said ..
Do you know what is the level of isolation of the processes within the sandbox? Makes sense that the SB processes are isolated within the SPUCWorkerProcess process.


On 11/28/2009 5:39:56 AM Claus said ..
Hi, were are the assemblies of a sandboxed solution deployed to ?


I just tried to find the dll of my sandboxed solution in the gac, but i can't find it as the dll's of my farm solutions.


Kind Regards


Claus


On 1/13/2010 5:32:30 PM Marc said ..
Regarding #3. I, and probably others deploy solutions that read/write to/from one site collection to another (Internet/Intranet scenarios). That means features like this wont run in the sandbox. Looks like the sandbox wont be for everyone then. Add another exception to #10 plz.


On 1/13/2010 6:14:44 PM Sahil Malik said ..
Marc - fair point. But could you create an initial farm webpart, and deploy subsequent webparts as configurations that are pure sandbox solutions?


On 1/25/2010 11:33:13 PM Srini said ..
Regarding Claus Question: "were are the assemblies of a sandboxed solution deployed to ?" Sandboxed solutions are deployed to database. Nothing will be available on file system including the assemblies; This is the major advantage with respect to isolation.


On 2/25/2010 2:40:32 AM Claus said ..
Hi, does anyone know whether it is possible to make any webservice call from another system into the the sandboxed solution which is providing our own webservice ? Thanks


On 2/25/2010 9:15:36 AM Nico said ..
Hi guys,

is there any chance for custom field types in a sandboxed solution?

Greetings,


Nico


On 2/25/2010 9:17:23 AM Nico said ..
Hi guys,

is there any chance for custom field types in a sandboxed solution?

Greetings,


Nico


On 6/1/2010 5:36:04 PM Ayman El-Hattab said ..
Nico,


As Sahil mentioned:


"Sandboxed solutions don’t write anything to the SharePointRoot (Previously known as the HIVE)" and "You also can’t deploy files to disk or add assemblies to the GAC in a sandboxed solution".

For creating Custom Field Types, you will need to deploy an XML file to SharePointRoot. That's why Custom Field types are not allowed in SandBoxed solutions.


On 6/3/2010 12:45:09 PM Amol Gore said ..
Hi Sahil,


Great Post.


Don't you think Sandbox solution is boon for Administrator [Administrator Friendly] and bane for developers [I am sure it will not liked by developers]. Too many restrictions.


Is there any way to develop code using mixed approach i.e farm based and sandbox?

Can we access dlls from bin directory or files from "Inetpub"?


Regards,


Amol


On 6/3/2010 4:50:07 PM Sahil Malik said ..
Thanks Amol.


No DLLs from bin are not accessible.


On 10/6/2010 6:58:13 AM Mohammad Rafey said ..
Answer to Claus question:

It is possible to make web service calls from another system into your Sandboxed Solution indirectly via Full Trust Proxies mechanism. All your service call related code would go into a well inspected/reviewed proxy code, which would have to be registered with SharePoint.

Regards,


Mohammad Rafey