Sandbox Architecture

It is important to understand the architecture of how sandbox solutions work before we can talk about restrictions and Proxies.
The word "sandbox" in computers is generally used to refer to a safe area where you can play, without damaging the outside hosting environment. The sandbox in SharePoint is implemented as a separate process where your sandbox solution code will run. In fact, there are three processes.

SPUCHostService.exe
Also known as the User Code Service. This service runs on each server on the farm that we are going to allow to work in the sandbox.
This is an important consideration, because this constitutes an important part around the administration of sandbox solution infrastructure, namely the load balancing aspects. Which you will be deciding while enabling the service.
How to enable it?
Central Admin --> System Settings --> Manage Services on Server

CAD

Enabling Service

Selecting the Load Balancing Strategy

SPUCWorkerProcess.exe
The sandbox worker process is where your actual code runs! This is in contrast to having the code run inside of w3wp.exe. This is why you don't have to restart the application pool every time your redeploy an sandbox solution.
If you wish to debug a sandbox solution, and for any reason why F5 debugging is not working, you will need to attach your visual studio debugger to the SPUCWorkerprocess.exe process.
It is important to note however that the sandbox solution management infrastructure of SharePoint 2010 can choose to destroy the SPUCWorkerProcess.exe anytime your code tries doing something naughty, such as an infinite resource crunching loop! So, during debugging, don't be too surprised if SharePoint kills your process without asking first.

SPUCWorkerProcessProxy.exe
Inside the SPUCWorkerProcess.exe sandbox, you have the ability to run only a subset of the Microsoft.SharePoint namespace. What does that subset include? In sandbox solutions, you are free to use the following:

1. All of Microsoft.SharePoint, except
1. SPSite constructor
2. SPSecurity
3. SPWorkItem and SPWorkItemCollection
4. SPAlertCollection.Add
5. SPAlertTemplateCollection.Add
6. SPUserSolution and SPUserSolutionCollection
7. SPTransformUtilities
2. Microsoft.SharePoint.Navigation
3. Microsoft.SharePoint.Utilities, except
1. SPUtility.SendEmail
2. SPUtility.GetNTFullNameandEmailFromLogin
4. Microsoft.SharePoint.Workflow
5. Microsoft.SharePoint.WebPartPages, except
1. SPWebPartManager
2. SPWebPartConnection
3. WebPartZone
4. WebPartPage
5. ToolPane
6. ToolPart

What if there is an instance where you need to use the full object model to perform your task? Here comes SPUCWorkerProcessProxy.exe. As the architecture shown, the proxy operations will be executed in full-turst and will have full object model support.

All we need to do are:

1. Decide on what task you wish to perform in the full trust proxy, and implement it as a class that inherits from Microsoft.SharePoint.Usercode.SPProxyOperation
2. Decide on what arguments need to be passed to the SPProxyOperation that you just created, this is a serializable class you implement that inherits from Microsoft.SharePoint.Usercode.SPProxyOperationArgs
3. Compile the above to classes in a DLL, strong name the DLL, put it in the GAC.
4. The above steps would create a full trust proxy, which you will then need to register for use with SharePoint.
5. Finally, you consume the proxy in a sandbox solution using the SPUtility.ExecuteRegisteredProxyOperation method.

 We will see the practical implementation of both Sandbox solution and a supporting proxy infrastructure in next post.