The Sandbox feature is a new option for the developer creating SharePoint 2010 solutions with Visual Studio 2010. In the past, the developer who needed to deploy a solution would also have to be an administrator in order to install the required .dlls in the Global Assembly Cache (or find an administrator to do it for them). With SharePoint 2010, this obstacle is removed for a large number of cases (unfortunately, as will become obvious in a bit, sandbox solutions can not substitute for full trust solutions).
SharePoint 2010 offers a subset of the platform that runs in a separate worker in order to exectute code, shielded away from the main worker that executes the SharePoint platform itself. However, since this is indeed a “subset” not all operations are allowed or possible.
This environment, created by the Sandbox, is up to the administrator to decide where and if it will run. In fact, not all of the Web Front Ends (WFE) need to run the Sandbox worker. The administrator will also be able to decide who can deploy Sandboxed Solutions and how many of the resources will be available to the Sandbox.
Technically, Sandboxed Solutions are derivatives of the common SharePoint Solution Package (WSP), which however are limited to running into a specific secure process: the sandbox worker.
The servers that execute Sandboxed Solutions (as already noted earlier, the administrators can decide which WFEs will run the sandbox so that not all of them will have to execute the extra processes) kick start three extra processes in order to execute the Sandbox. These are:
1. SPUCHostService.exe : this is the process that will decide whether the specific Web Front End (WFE) will participate in the execution of the specific Sandboxed Solution. As mentioned earlier, not all of the WFEs need to execute the Sandbox (it is in fact in the administrator’s discration to decide which ones will), but also, the WFEs instead can decide whether or not they will participate in the execution of a specific Sandboxed Solution. This is because SharePoint servers do in fact support load balancing which, in case it has been implemented, allows the servers to decide which ones will participate in the execution of code.
2. SPUCWorkerProcess.exe : this is the w3wp.exe equivalent for the Shandboxed solutions. It is the host process that will execute the Sandboxed Solution just like the w3wp.exe would execute a full trust SharePoint Solution Package. In face, it is essential for the developer to make note of this process because, if at any point they attempt to debug a Sandboxed Solution, they will need to attach the debugger to this process!
3. SPUCWorkerProcessProxy.exe : This is a new part of the services application arcitecture for SharePoint. It goes right between the web applications and the ervice applications and decides whether a particular web application is permitted to access a specific service application. (note: it is talking about service application. NOT web services. A service application is a long-running executable application that runs in its own Windows session, can be automatically started when the computer boots, be paused and restarted, and does not show any user interface! It is what the the old NT Services were)
The following diagram, borrowed from the wrox “Professional SharePoint 2010 Development” illustrates the above description about how SandBoxed applications execute:
Powered by Zoundry Raven
[…] 1,2,3,4 Like this:LikeBe the first to like this post. […]
[…] Microsoft Visual Studio 2010 offers a very handy way to develop code (eg. a web part) for SharePoint 2010 in two flavours. You can either develop an application that will have full access to SharePoint features and resources (and which will require a SharePoint Administrator to install) or you can develop a SandBoxed solution that will not have the same access level but which can be installed by site collection owners without administrator rights. For more information on Sandboxed Solutions make the jump to the introduction post. […]