Difference between Sandboxed Solution and Farm Solution

Farm Solutions:

·         Hosted in the IIS worker process (W3WP.exe), run code that can affect the whole farm.

·         If you deploy any feature or retract any feature the whole application pool got recycled.

• Since they are scoped as farm level, they have full trust access to all the resources.
• When the Sand boxed Solution property is set to False, selecting Build\Deploy will deploy the solution to the Farm Solution Gallery.
• Farm solutions are installed and deployed

Sandboxed Solutions:

• Sand boxed solutions are hosted in the SharePoint user code solution worker process (SPUCWorkerProcess.exe).
• It never restart the IIS application pool
• Scoped at Site collection level
• When the Sandboxed Solution property is set to True, selecting Build\Deploy Solution deploys the solution to the site collection Solution Gallery.
• Sandboxed solutions are uploaded and activated.
• We can't create Application pages in Sandbox solutions.Beacuse Application pages are stored in the 14\TEMPLATES\_LAYOUTS and when we deploy as sandbox we don’t have permissions to the physical folder.
• We can’t create VISUAL web parts in Sandbox solutions.
• We can’t use code to connect to the external web services or to database
• Visual Studio attaches the debugger to the SPUCWorkerProcess process that the SPUserCodeV4 service in SharePoint automatically triggers and controls

Here the processes which required for Sandbox solutions.

1. SPUCWorkerprocess.exe - Sandbox Worker process service which is a Seperate Service Application which actually executes Sandbox code. It should be started in every farm to use Sandbox solutions.
2. SPUCWorkerProcessProxy.exe - Sandbox Worker process proxy which is working as a proxy for Worker process and takes care of Sandbox code execution. It can also serve to other farms if configured. Basically it helps site administrator for load balancing.
3. SPUCHostService.exe - Sandbox User Code Service takes care of user code in Sandbox amd it can be started in the farms where to use Sandbox solutions.

Sandbox Limitations:

As I said before, Sandbox is a secured wrapper and it has restrictions on code to run in SharePoint environment. Few key limitations which developers should know are listed below.

1. No Security Elevation - RunWithElevatedPrivileges which runs the specified block of code in application pool account(typically System Account) context is not allowed in Sandbox code. SPSecurity class also not allowed to use in Sandbox.
2. No Email Support - SPUtility.SendMail method has been blocked explicitly in Sandbox, However .Net mail classes can be used to send mails. Additionaly sandbox won't allow to read Farm SMTP address. So developers has to specify the SMTP address in code itself(may be some other workaround).
3. No Support to WebPartPages Namespace - Sandbox won't allow to use Microsoft.SharePoint.WebPartPages namespace.
4. No Support to external Webservice - Internet web service calls are not allowed to ensure security in Sandbox solutions. Allow Partially Trusted code also can't be accessed within Sandbox.
5. No GAC Deployment - Sandbox solutions are not stored in File System(Physical path) and assemblies can't be deployed to Global Assembly Cache(GAC). But it's available on C:\ProgramData\Microsoft\SharePoint\UCCache at runtime. Note the ProgramData is a hidden folder.
6. No Visual Webparts - Visual Studio 2010 by default won't allow to create Visual Webparts to deploy as sandbox solution. But with Visual Studio PowerTools extensions(downloadable from Microsoft MSDN website) Visual Webparts can be developed and deployed as sandbox Solutions