Why Sandbox came into Existence?
Each server in the farm can have multiple web applications running on it. A web application can in turn have one or more site collections, and a site collection has one or more sites. Farm solutions can impact the entire SharePoint system and are available to all site collections and sites in the farm. This is sometimes desirable, but sometimes can have undesired effects because a farm solution that is misbehaving can impact all sites and site collections in the system.
- Sandboxed solutions are deployed at the site collection level rather than the farm level, so this lets you isolate a solution so it is only available to one site collection within the farm.
- Sandboxed solutions also run in a separate process from the main SharePoint IIS web application
- Process and the separate process is throttled and monitored with quotas to protect the SharePoint site from becoming unresponsive due to a misbehaving sandboxed solution.
- It is worth mentioning that sandboxed solutions solve an organizational problem as well—in many organizations it is difficult to get permission to install a farm solution because of the possible impact that could have on the SharePoint system. System administrators in charge of running a Share-Point site have been reluctant in the past to allow custom solutions to run on their sites. With the advent of SharePoint 2010, there is now a robust system in place to monitor and throttle these custom solutions so that system administrators don’t have to worry about a custom solution bringing the entire SharePoint site down.
There are restrictions on the kinds of solutions you can build with a sandboxed solution.
The most significant restrictions disallow creation of
- application pages
- visual web parts
- code-based workflows with a sandboxed solution.
Sandboxed Solution Considerations
Sandboxed solutions are a feature in Microsoft SharePoint 2010 that enables site collection users to upload their own custom code solutions. A common sandboxed solution is users uploading their own Web Parts.
A sandboxed SharePoint application runs in a secure, monitored process that has access to a limited part of the Web farm. Microsoft SharePoint 2010 uses a combination of features, solution galleries, solution monitoring, and a validation framework to enable sandboxed solutions.
Specifying Project Trust Level
Visual Studio supports sandboxed solutions through a Boolean project property called Sandboxed Solution. This property can be set at any time in the project, or it can be specified when you create the project in the SharePoint Customization Wizard.
Note:- Changing the Sandboxed Solution property of a project after it is created may cause validation errors.
If the Sandboxed Solution property is set to false, or you select the Deploy as a farm solution option, then the solution is considered a farm-scoped solution. However, if the Sandboxed Solution property is set to true, or you select the Deploy as a sandboxed solution option in the wizard, then the solution is treated differently than a farm solution.
To understand how sandboxed solutions work, it helps to know that SharePoint sites are hierarchical in scope. The top element is known as the Web farm, and other elements are subordinate to it:
Web Farm
Web Application A
Site Collection A1
Site A1a
Web Application B
Site Collection B1
Site B1a
Site B1b
Site Collection B2
Site B2a
As you can see, Web farms can contain one or more Web applications, which in turn can contain one or more site collections, which can have subsites, and so on. Changes made to one site collection affect only that site collection and no other. However, changes made at the Web farm level affect all site collections on the farm.
Windows SharePoint Services (WSS) 3.0 allows you to deploy solutions only to the farm level, but Microsoft SharePoint Foundation 2010 allows you to deploy to either the farm level (farm solution) or the site collection level (sandboxed solution).
In WSS 3.0, solutions could be deployed only to the farm level. This meant that potentially harmful or destabilizing solutions could be deployed that affected the whole Web farm and all of the other site collections and applications that run under it. However, by using sandboxed solutions, you can deploy your solutions to a subarea of the farm, a specific site collection. To provide additional protection, the solution’s assembly is not loaded into the main IIS process (w3wp.exe). Instead, it is loaded into a separate process (SPUCWorkerProcess.exe). This process is monitored and implements quotas and throttling to protect the farm from sandboxed solutions that perform harmful activities, such as running tight loops that consume CPU cycles.
Windows SharePoint Services 2010 has a feature known as the "site collection solution gallery" available either by clicking Site Actions, then Site Settings, then Galleries, and thenSolutions in the SharePoint site, or in the SharePoint 2010 Central Administration page. Solution galleries are repositories of solutions that enable site collection administrators to manage solutions in their site collections.
The solution gallery is a document library stored in the root Web of the SharePoint site. The solution gallery replaces site templates and supports solution packages. When a SharePoint solution package (.wsp) file is uploaded, it is processed as a sandboxed solution.
When a sandboxed solution is deployed, the array of SharePoint functionality available to it is limited to help reduce any security vulnerabilities it may have. Some of these limitations include the following:
- Sandboxed solutions have a restricted subset of deployable solution elements available to them. Potentially vulnerable SharePoint project templates, such as site definitions and workflows, are not available.
- SharePoint runs sandboxed solution code in a process (SPUCWorkerProcess.exe) separate from the main IIS application pool (w3wp.exe) process.
- Mapped folders cannot be added to the project.
- Types in the Microsoft SharePoint Server 2010 assembly Microsoft.Office.Server cannot be used in sandboxed solutions. Also, only types in the Microsoft SharePoint Foundation 2010 assembly Microsoft.SharePoint can be used in sandboxed solutions.
It is important to note that specifying a SharePoint solution as a sandboxed solution has no affect on SharePoint server; it only determines how the SharePoint project is deployed to SharePoint from Visual Studio and what assemblies it binds to. It does not affect the generated .wsp file, and the .wsp file has no data that directly correlates to the Sandboxed Solutionproperty.
Sandboxed solutions support the following capabilities and elements:
- List Definitions
- List Instances
- Onet.xml
- WebTemplate feature elements (instead of Webtemp.xml)
- Content Types/Fields
- Navigation
- Module/files
- Feature callouts
- Web Parts
- Support for all Web Parts that derive from System.Web.UI.WebControls.WebParts.WebPart
- Event receivers
- SPItemEventReceiver
- SPListEventReceiver
- SPWebEventReceiver
- Custom actions
- Declarative workflows
- Visual Web Parts
- Application Pages
- Custom Action Group
- HideCustomAction element
- Content Type Binding
- Web Application-scoped features
- Farm-scoped features
- Workflows with code
10 reasons to use Sandboxed Solutions
- Sandboxed solutions are secure.
- Sandboxed solutions can be monitored.
- Sandboxed solutions do not affect other sandboxed solutions, well atleast not in other site collections is what I mean.
- Sandboxed solutions do not touch the file system for the most part
- Sandboxed solutions skip application pool recycles, so debugging is not such a pain.
- Sandboxed solutions allow the site collection administrator to perform deployment and upgrades
- Sandboxed solutions make CAS policies look like the out of style hairstyles of 1980s
- The Solution validation framework for sandboxed solutions is exntensible, simply inherit from the SPSolutionValidator base class.
- Sandboxed solutions remove the need for line by line code reviews
- Sandboxed solutions allow you to offer different level of SLAs to different site collections using Resource Quotas.
No comments:
Post a Comment