Whenever a solution is to be deployed in a partially trusted environment it’s being deployed as a sandbox solution. This helps in providing a stable SharePoint farm by restricting actions that can cause problems with performance, security and other areas. This stability is achieved by restricting the custom solutions on the basis of Custom Access Security (CAS) policy and by restricting the access some portions of the object model.
Therefore it’s always being recommended to the developers to deploy and test the solution in a Sandbox Environment before deploying the same in the farm solution.
Enabling the use of Sandbox solution requires enabling the User Code Service in windows environment. This service can be enabled by logging on to the Central Administration >> System Settings >> Manage Services on Server.
Whenever the Sandbox Solution property is set to true, selecting Build/ Deploy Solution deploys the solution to the Site Collection Solution Gallery.
There is a terminology difference between Sandbox and Farm Solution and i.e. Farm Solutions are installed and deployed while Sandbox Solution are uploaded and activated. Activation of any Sandbox Solution automatically activates any feature scoped to the level of Site Collection.
Sandbox Solution can be deployed by the Site Collection Administrator and hence doesn’t require Farm Administrator like in the case of Farm Deployment.
Another feature that Sandbox Solution provides is that the solution can be upgraded whenever we upload a new version the system detects on the basis of id that a previous solution is uploaded with some upgrades and hence uninstall the previous version and installs the updated version on the same solution.
Although the User Code Service is responsible for managing the Solution Solutions; The Execution Manager, The Worker Service, and the Worker Service Proxy is also responsible for managing the solutions as being shown in the below given diagram:
Execution Manager handles the load and execution of the Sandbox Solution Code. Execution Manager works in the IIS Application pool and is responsible for calling User Code Service (SPUCHostService.exe) requesting that a sandbox solution is loaded.
The user code service makes a request to the worker process (SPUCWorkerProcess.exe) to load the sandbox solution
Although the worker service utilizes the same framework as other services in the SharePoint farm it cannot make a direct connection to the Worker Service Proxy. Instead you simply configure the User Code Service for a Server.
Once the assembly of a Sandbox Solution is loaded into the Worker Service, its code can be executed. A pool of application domains is maintained within SPUCWorkerProcess.exe, and an available AppDomain is used to execute the request. Only one request at a time is executed in any AppDomain, so there won’t be conflicts between the solutions.
Sandbox System components are found in the 14 hive which is SharePoint System Directory:
C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\UserCode.
Here you can find SPUCHostService.exe, SPUCWorkerProcess.exe, and SPUCWorkerProcessProxy.exe. Along with the executables, you’ll also find a web.config file that references the CAS policy restrictions in the file C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\CONFIG\wss_usercode.config. Finally, this folderalso contains a subfolder named \Assemblies. The Assemblies folder contains the assemblies Microsoft.SharePoint.dll, Microsoft.SharePoint.SubsetProxy.dll, and Microsoft.SharePoint. UserCode.dll, which support the object model subset and creation of full-trust proxies.