Blog Address Http://blog.csdn.net/foxdaverecently read a book just see About the sandbox solution introduction, then tidy up the record. while sandboxed solutions have been deprecated in the latest SharePoint development (replaced by the app), I think it's no harm to use something simple, such as the one mentioned in Linyu's article . See " choosing the right set of APIs in SharePoint 2013 " for details.
let's go back to the SharePoint development Interface History
SharePoint 2007 (before 2007 is not familiar, but should be similar to 2007): This is the world of the solution (or the sandbox solution is not), and the WSP solution package needs to be manually generated, is primitive; SharePoint provides webservice for remote calls, and can do a lot of things.
SharePoint 2010: sandboxed solutions have appeared. At the same time, the client object Model (CSOM) is also added to the API. With Visual Studio 2010, the generation of solutions has also become intelligent, freeing developers from tedious packaging deployment and greatly reducing commissioning time. See "Deciding which SharePoint API to use" for details.
With the advent of the SharePoint 2013:sharepoint app, the accompanying development interface has become enriched, with links to the details.
Back to our focus, sandboxed solutions.
A sandbox is a restricted execution environment that enables programs to access only certain resources and causes problems that occur in the sandbox to not affect the rest of the server environment. Solutions that are deployed to the sandbox are called sandboxed solutions, and they cannot use certain computers and network resources, nor can they access content outside the site collection to which they are deployed.
Because sandboxed solutions do not affect the entire farm, it does not have to be deployed by a farm administrator. Sandboxed solutions can be deployed by site collection administrators, or, in some cases, by users who have Full Control permission levels on the root of the site collection. However, only a farm administrator can configure sandboxed solution-related settings, such as load balancing, tiers, quotas, and resource points, and only farm administrators can elevate sandboxed solutions to run directly in a farm outside the sandboxed environment.
Sandboxed solutions are suitable for use in the following two common scenarios:
The organization wants to run the employee code on the SharePoint Server production site, and this code is not rigorously reviewed and tested.
The host wants to have the owner of the hosted SharePoint Server site upload and run custom code.
The key benefits of using sandboxed solutions are as follows:
Sandboxed solutions can be added to a SharePoint Server production environment without the risk of affecting processes outside the sandbox.
Site collection administrators can deploy sandboxed solutions. This frees the farm administrator from this task.
Because the sandbox runs in a separate process that is subject to quota limits and can monitor its impact on the farm, it adds scalability and flexibility.
You can move the solution out of the sandbox and run directly in the farm without having to modify or recompile the solution.
Because of the limitations of sandboxed solutions, there must be something that cannot be achieved, including the following:
Connect to a resource that is not on the local server farm.
? access the database.
? change the threading model.
? Call unmanaged code.
? write to disk.
Access resources from different site collections.
The following is a detailed comparison of the difference between a farm solution and a sandboxed solution
Farm Solutions:
Runs in the IIS worker process (W3WP.EXE).
Running code in the farm solution affects the entire farm.
When you deploy or recycle any feature, it causes the entire application pool to be recycled.
Because the scope is the farm level, they have full trust access to all resources.
Sandboxed Solutions:
Run in the SharePoint user code solution worker process (SPUCWorkerProcess.EXE).
the process runs on the CAS policy is restricted from accessing any resources outside the sandbox, so it never restarts the IIS application pool.
Running code only affects the site collection in which the solution resides.
Attention:
The farm solution is to install and deploy, and sandboxed solutions are uploaded and activated.
Sandboxed Solutions cannot create an application page under Templates/_layouts, and the deployed sandboxed solution does not have permission to access the file system physical path.
Sandboxed solutions cannot create Visual Web Parts (available in SharePoint 2013, but make sure that the class objects used are not limited and that the layout folder is not used).
Sandboxed Solutions cannot use code to link to external Web services or databases.
Some API classes are not available.
Aspect |
Field |
Sand Box |
Deployment process |
Add the solution, and then deploy it to the farm. |
Upload the solution to a site collection, and then activate it in the site collection. |
People that can be deployed |
server farm Administrator. |
If the solution contains an assembly, only the site collection administrator can deploy it. If the solution does not contain an assembly, users who have Full Control permission levels on the root of the site collection can deploy it. |
Data access |
Not restricted. |
Solutions can only access content in the site collection to which they are deployed. |
Processes that run the solution |
An unrestricted IIS worker process, or any process to which the solution is deployed. |
Individual permissions are restricted by the worker process. |
Code Access security |
Solution developers can set code access security policies when they package their solution. |
be restricted. |
Monitoring |
not be monitored. |
is monitored and is subject to a quota limit set by the farm administrator. |
Load Balancing |
Depending on the type of solution. |
Can be configured separately from a non-sandboxed solution. |
Solution Features |
Not restricted. |
be restricted. |
Supplementary reading:
Sandboxed Solutions Overview (SharePoint Server 2010)
What you can implement in a sandboxed solution
Limitations of sandboxed Solutions
Top Ten reasons to use Sandboxed Solutions
Top Ten things to consider when writing SandBoxed Solutions
SharePoint sandboxed Solutions VS Farm Solutions