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.