Sandbox Development
With SharePoint, the challenge has always been the balance between creating solutions and deploying them in a way that you can trust will not damage or impair the SharePoint farm.
A new feature in SharePoint 2010, called sandboxed solutions, addresses many of these concerns, enabling farm administrators to feel comfortable that the SharePoint farm is safe, giving site collection administrators the authority to manage the applications in their site collection, and providing developers with the flexibility to create solutions they know will be deployed in a safe and rapid manner.
Because sandboxed solutions cannot affect the whole server farm, they do not have to be deployed by a farm administrator. Sandboxed solutions can be deployed by a site collection administrator or, in certain situations, by a user who has the Full Control permission level at the root of the site collection.
Benefits of Sandboxed Solutions
The main benefits of using sandboxed solutions are as follows:
- Sandboxed solutions can be added to a production SharePoint Server environment without the risk of affecting processes outside the sandbox.
- Scalability and flexibility are increased because sandboxes run in a separate process that can be restricted by quotas, and their effect on the farm can be monitored.
- A solution does not have to be modified or recompiled if it is moved from a sandbox to running directly on the farm.
Restrictions (and Workarounds) on Sandboxed Solutions
The following list identifies the most common things that an assembly that will run in a sandbox cannot do:
- Connect to Resources That Are Not Located on the Local Farm
- Access a Database
Sometimes, you may want to view and edit data from one of your core business systems. To access that data, you can use a “Hybrid Approach”. One such approach involves creating an external content type for the line of business data, then using the SPList API in the sandbox to work with that data. This is less of a workaround and more of a structured approach to working with external data in a sandboxed solution.
- Change the Threading Model
- Call Unmanaged Code
- Write to Disk
You can write to SharePoint lists in a sandboxed solution. You can use a full-trust proxy with the SharePoint Logger to write to the Windows Event Log and SharePoint Unified Logging Service (ULS) logs.
- Access Resources in a Different Site Collection
- Developing Visual Web Parts
Visual Studio 2010, out of the box, does not allow you to use the visual editor to create Web Parts for a sandboxed solution. Microsoft has provided a Visual Studio 2010 Power Tool for SharePoint 2010 developers. In addition to allowing for visual editing of sandboxed Web Parts, this Power Tool provides some helpful compiler tips.
- Writing Fully Coded Workflows
You should consider using declarative workflows in a sandbox and deploying coded workflows as a farm solution when environment allows for it.
Validating Solutions in the Sandbox
The SharePoint sandbox framework provides an additional way for farm administrators to monitor and validate solutions that run in the sandbox. Farm administrators can deploy solution validators that run when a solution is uploaded to a Solution Gallery. Administrators can create validators that allow only code signed with a particular certificate to run, for example, or they can create a validator to allow only Web Parts. Another good use for validators is to log and catalog solutions in the farm as they are activated. You can see how this simple but powerful tool helps farm administrators get a handle on the solutions running in the farm.
Each solution validator is called when a solution is activated. If the validator is updated, solutions are validated again the next time they are executed.
References
The post SharePoint 2010 : Sandbox Development in nutshell appeared first on Manas Bhardwaj's Stream.
