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.
Technically speaking
SharePoint solutions run in seperate worker processes and not in w3wp.exe. So It doesn't require IIS Reset or Application
Pool Recycling. Without disturbing the SharePoint site, Sandbox solutions
can be deployed. Only thing while deploying new version of Sandbox solution
over existing solution, SharePoint will display No Solution found error in
Sandbox Webparts on the page. However within seconds sandbox solutions getting
deployed and it'll start working. In SharePoint 2007, only farm administrators
can install/deploy developer solutions. But Now site collection administrators
can deploy solutions with web based interface. This reduces the dependency of
Farm Administrator and improves rapid deployment.
You can also have the
solutions as you have in SharePoint 2007, but those solutions will be called
farm solutions. Sandboxed solution is per site collection. Sandboxed solution’s
deployment is different than normal solutions. Every site collection in
SharePoint 2010 has a library for sandbox solutions. You simply need to upload
your solution (wsp) to this library. And then activate the solution. So no
server reset is required.
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 then Solutions 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.
Sandbox Processes
Here the processes which required for Sandbox solutions.
Here the processes which required for Sandbox solutions.
1.
SPUCWorkerprocess.exe -
Sandbox Worker process service which is a Seperate Service Application which
actually executes Sandbox code. It should be started in every farm to use
Sandbox solutions.
2.
SPUCWorkerProcessProxy.exe
- Sandbox Worker process proxy which is working as a proxy for Worker process
and takes care of Sandbox code execution. It can also serve to other farms if
configured. Basically it helps site administrator for load balancing.
3.
SPUCHostService.exe -
Sandbox User Code Service takes care of user code in Sandbox amd it can be
started in the farms where to use Sandbox solutions.
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 Solution property.
As I said before, Sandbox is a secured wrapper and it has restrictions on code to run in SharePoint environment. Few Key limitations which developers should know are listed below.
1.
No Security Elevation - RunWithElevatedPrivileges which runs the
specified block of code in application pool account(typically System Account)
context is not allowed in Sandbox code. SPSecurity class also not allowed to
use in Sandbox.
2.
No Email Support - SPUtility.SendMail method has been blocked
explicitly in Sandbox, However .Net mail classes can be used to send mails.
Additionaly sandbox won't allow to read Farm SMTP address. So developers has to
specify the SMTP address in code itself(may be some other workaround).
3.
No Support to WebPartPages Namespace - Sandbox won't allow to use
Microsoft.SharePoint.WebPartPages namespace.
4.
No Support to external Webservice - Internet web service calls are not allowed to
ensure security in Sandbox solutions. Allow Partially Trusted code also can't
be accessed within Sandbox.
5.
No GAC Deployment - Sandbox solutions are not stored in File System(Physical
path) and assemblies can't be deployed to Global Assembly Cache(GAC). But it's
available on C:\ProgramData\Microsoft\SharePoint\UCCache at runtime. Note the
ProgramData is a hidden folder.
6.
No Visual Webparts - Visual Studio 2010 by default won't allow to
create Visual Webparts to deploy as sandbox solution. But with Visual Studio
PowerTools extensions(downloadable from Microsoft MSDN website) Visual Webparts
can be developed and deployed as sandbox Solutions.
7.
Farm solutions run with
full trust, whereas sandbox solutions mark as partially trusted solution. The
major difference is the way of deployment. You can run the same solution under
full-trust, but then you need to deploy it as a farm solution. As you do in
SharePoint 2007.
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
Sandboxed solutions do
not support the following capabilities and elements:
·
Visual Web Parts
·
Application Pages
·
Custom Action Group
·
HideCustomAction element
·
Web Application-scoped
features
·
Farm-scoped features
·
Workflows with code
