SharePoint sandbox Solution VS field solution, sharepoint sandbox

SharePoint sandbox Solution VS field solution, sharepoint sandbox
Blog address ghost. Although the sandbox solution has been rejected and abandoned (replaced by an APP) in the latest SharePoint development, I think some simple things are useless, for example, the scenario mentioned in the article of Yu. For details, see "select the correct API set in SharePoint 2013 ".
Let's review the history of the SharePoint development interface.

● SharePoint 2007 (versions earlier than 2007 are not very familiar, but should be similar to 2007): This is the world of field solutions (or the sandbox solution is not yet available ), in addition, WSP solution packages must be manually generated, which is simple and primitive. At the same time, SharePoint provides WebService for remote calls and many operations can be performed.

● SharePoint 2010: The Sandbox solution emerged. In addition, the client Object Model (CSOM) is added to the API ). With Visual Studio 2010, the generation of solutions has become intelligent, freeing developers from the tedious packaging and deployment process, greatly reducing debugging time. For details, see "determine the SharePoint 2010 API to use ".

● SharePoint 2013: The SharePoint APP has been launched, and the Development interfaces have also become richer. For details, refer to the above link.

Back to our focus, Sandbox solutions.

A sandbox is a restricted execution environment that allows programs to only access certain resources and prevents problems occurring in the sandbox from affecting the rest of the server environment. A solution deployed in a sandbox is called a sandbox solution. They cannot use certain computer and network resources or access content other than the website set to which they are deployed.

Because the sandbox solution does not affect the entire server farm, it does not need to be deployed by the server farm administrator. The Sandbox solution can be deployed by the website set administrator or, in some cases, by a user with full permission to the root directory of the website set. However, only the server farm administrator can configure sandbox solution settings (such as load balancing, layers, quotas, and resource points), and only the server farm administrator can upgrade the sandbox solution, make it run directly in the server farm outside the sandbox environment.

Sandbox solutions are suitable for the following two common scenarios:

• The organization wants to run the employee code on the SharePoint Server production website without strict review and testing.

• The host wants the owner of the SharePoint Server website to upload and run custom code.

The main advantages of sandbox solutions are as follows:

• You can add the sandbox solution to the SharePoint Server production environment without the risk of affecting the process outside the sandbox.

• The website administrator can deploy the sandbox solution. This frees the server farm administrator from this task.

• As sandbox runs in a single process that is subject to quota restrictions and can monitor its impact on the server farm, it increases scalability and flexibility.

• You can remove the solution from the sandbox and run it directly on the site without modifying or re-compiling the solution.

Because of the limitations of the sandbox solution, some things cannot be implemented, including:

• Connect to resources that are not on the local server farm.
• Access the database.
• Change the thread model.
• Call unmanaged code.
• Write to disk.
• Access resources from different websites.

The following compares the differences between the field solution and the sandbox solution in detail.

Field solution:

Run in the IIS Working Process (W3WP. EXE.

Running the code in the solution affects the entire field.

When any function is deployed or recycled, the entire application pool is recycled.

Because the range is field-level, they have full access permissions to all resources.

Sandbox solution:

Run in the SharePoint user code solution workflow (SPUCWorkerProcess. EXE.

This process runs under the CAS policy and is restricted to access any resources outside the sandbox, so it never restarts the IIS application pool.

The Running code only affects the website set where the solution is located.

Note:

The field solution is installation and deployment, and the sandbox solution is upload and activation.

The Sandbox solution cannot be created on the application page under TEMPLATES/_ LAYOUTS. The deployed sandbox solution does not have the permission to access the physical path of the file system.

The Sandbox solution cannot create visual Web Components (this is available in SharePoint 2013, but make sure that the class objects used are not restricted and the layout folder is not used ).

The Sandbox solution cannot use code to link external Web services or databases.

Some APIs cannot be used.

Aspect	Field	Sandbox
Deployment process	Add a solution and deploy it on site.	Upload the solution to the website set and activate it in the website set.
Deployer	Server farm administrator.	If the solution contains an assembly, only the website set administrator can deploy it. If the solution does not contain an assembly, you can deploy it if you have full permission to the root directory of the website set.
Data Access	Not limited.	The solution can only access the content in the centralized website deployed.
Processes running the solution	Unlimited IIS working processes, or any process to which the solution is deployed.	Work processes with limited permissions.
Code access security	Solution developers can set code access security policies when packaging solutions.	Restricted.
Monitoring	Not monitored.	Monitored and limited by the quota set by the server farm administrator.
Load Balancing	No, depending on the type of solution.	It can be configured separately from the non-sandbox solution.
Solution features	Not limited.	Restricted.

Additional reading:

Sandbox solution Overview (SharePoint Server 2010)

What can be implemented in the sandbox solution?

Limitations of sandbox Solutions

Top 10 reasons to use Sandboxed Solutions

Top 10 things to consider when writing SandBoxed Solutions