Briefly describe the sandbox solution in SharePoint 2010

When programmers use Visual Studio 2010 to create applications for SharePoint 2010, you can create two types of solutions, a server farm solution, and a sandbox solution. For example, when you open Visual Studio 2010 and create a new blank SharePoint project, the first interface you see is the following dialog box.

A server farm solution (or simply a farm solution) and SharePoint 20,071 are a fully trusted solution. A farm solution can contain all of the SharePoint components and elements that can be put into the solution package, such as application pages, Visual Web Parts, and so on. Installing a farm solution package on a SharePoint 2010 system requires your system administrator to open a command prompt window or a PowerShell window on the SharePoint server, and enter the appropriate command line directive or cmdlet. Install this farm solution package into the SharePoint server farm.

If your client has a strict control process for the SharePoint system, you're in the doghouse. After you've worked hard to fix all the bugs in the code, package the project into an updated solution package, and then, as a developer, you have to fill out n forms, and then just wait for the IT staff managing the server farm to help you deploy the updated solution package to the server farm. Because only they have permission to operate directly on the server. If the customer needs you to explain each time, what does every update do, and how the impact on the server, you will be more head.

So SharePoint 2010 introduces the concept of a sandbox solution. Speaking of "sandbox", well, it's good stuff. Over the years, the entire development platform revolves around the sandbox, the JVM is a sandbox, and the CLR is a sandbox. With the "sandbox", you can limit the custom code to it, even if it accidentally crash off, it can minimize the impact.

The SharePoint sandbox solution works almost as well. If a developer creates its own SharePoint 2010 project as a sandbox solution, SharePoint 2010 runs the sandbox solution in a specific sandbox and monitors the operation of the code inside the sandbox at any time.

For the code contained within a farm solution, most of the other components, such as Web Parts, pages, event handlers, and so on, are loaded into the w3wp.exe process, with the exception of a few components. This is a matter of course, because SharePoint is a asp.net Web application, so various custom code will naturally be loaded into w3wp.exe process by ASP.net runtime.

But if it is a sandboxed solution, the code it contains will run in a separate process (and, to be exact, several processes are used to run the code in the sandbox solution) rather than the w3wp.exe process.

For example, a developer packs a custom Web Part into a sandbox solution package, deploys it to a site collection and activates it, and then places the Web Part on a page. When a user accesses the page, W3wp.exe discovers that the custom code contained in that Web Part needs to be run, at which point the W3wp.exe process contacts the SPUCHostService.exe process (on either the local or remote server) and tells it that it needs to "sandbox" The model executes some code. The SPUCHostService.exe process notifies the SPUCWorkerProcess.exe process to load code that needs to be run, and the SPUCWorkerProcess.exe process is completed by SPUCWorkerProcessProxy.exe to Sharepoi The NT object model, and executes the custom code in that Web Part. After the execution of the Code, the results of the execution are eventually returned to the W3wp.exe process, and w3wp.exe gets the results of the custom Web Part execution and continues with the page.

To perform a sandboxed solution on a SharePoint 2010 server farm, you need to start the Microsoft SharePoint Foundation sandbox Code Service on at least one server. Open the Services on Server page from SharePoint 2010 Central Administration to start or stop the service on the specified physical server.

If your server farm contains n servers, you can start the Microsoft SharePoint Foundation Sandbox Code service on all physical servers, or you can select only one of several application servers to start Microsoft SharePoint Foundation sandbox Code Service ". Even most extreme, you can prepare a server that is both CPU and memory powerful, join the server farm, and then run the Microsoft SharePoint Foundation sandbox Code Service exclusively on this server. In this way, no matter which front-end server in the server farm needs to run custom code in the sandbox solution, these requests are sent to this powerful physical server. If the custom code in the sandbox solution is bad, it can seriously affect the CPU or memory resources of the server running the code, and it will only affect this particular server.

When the w3wp.exe process needs to find a place to run the sandbox code, it is based on some kind of predetermined strategy. SharePoint 2010 has two policies available: 1, always run sandbox code on the same server that is being requested, 2, and use a built-in optimization rule to pass execution requests. The 1th strategy is very simple, and w3wp.exe always passes the request to execute the sandbox code to the SPUCWorkerProcess.exe process on the server, where the current server is responsible for running the sandbox code. The 2nd strategy is similar to a load balancing mechanism, where SharePoint checks which servers in the farm can be used to run sandboxed code and then, following an optimization rule, allows W3wp.exe to pass requests to execute code to a server. This optimization rule is simply that, if server A had executed a Web Part code in a sandbox solution last time, the next priority would be to continue to let server a execute the code inside the same Web Part.

To choose which policy to select, you can open the system settings-Manage User Solution page in SharePoint 2010 Central Administration and then select one of the 2 policies.