SharePoint 2010's Sandboxed Solutions

One of the biggest problems with SharePoint 2007 development is that all of its solutions run as full trust. This makes farm administrators reluctant to publish any solution that may disrupt the stability of the farm. Sandboxed solutions, new in SharePoint 2010, address this by allowing site collection administrators to deploy solutions that are safe to run.

You can monitor sandboxed solutions and place restrictions on the resources, such as memory and CPU cycles, they can use. The sandboxed solution framework protects SharePoint farms by running solutions in a separate process that is restricted by .Net Code Access Security policy.

Sandboxed solutions are restricted to running under a subset of the SharePoint API and the framework can monitor these solutions and shut down any that risk the stability of the farm.

Sandboxed solutions are aimed at creating business agility, letting businesses react to changing needs by quickly creating and deploying solutions. Businesses can deploy these solutions rapidly because there's less risk and less need for a review process to slow them down.

Site collection administrators can even deploy third-party solutions without fear of bringing down the entire farm. This is better than how you deploy solutions in SharePoint 2007, where—if new solutions are allowed at all—it could take weeks or months to work through the farm administrator's validation and testing process.

Farm solutions, also known as full trust solutions, are what you deploy in SharePoint 2007. They're deployed by a farm administrator and are scoped to the farm level.

They have full trust access to all resources and functionality in SharePoint and, when deployed, require you to IISReset. This reset cause disrupts everyone else who uses your server and can be difficult to manage when you have a large number of tenants or critical applications on a server.

Farm solutions aren't monitored through the resource monitoring framework that sandboxed solutions use, and a farm administrator can't throttle their resource usage or automatically shut down a misbehaving solution.

Solution Gallery, shown in Figure 1 is a new document library that site collection administrators can use to upload and manage sandboxed solutions.

SharePoint .wsp solution files are uploaded to the Solution Gallery the same way that other documents are uploaded to document libraries: in production environments, site collection administrators will normally use the web user interface, and during development, Visual Studio uses the SharePoint API to programmatically upload and activate the solutions.

Solution Types

The first question that developers have when they hear about sandboxed solutions is what types of solutions they can create in a sandbox. A good general rule is that you can do almost anything, as long as it's scoped to the site collection where the solution is deployed.

The sandbox API is a subset of the full SharePoint API , but most of SharePoint's classes are available, including SPSite, SPWeb, SPList, and SPListItem. (The complete list of what APIs are allowed in sandboxed solutions is documented in the SharePoint SDK.)

The available classes include those most commonly used when creating business applications you'd want to deploy quickly. Other types of SharePoint objects available include Web Parts, modules, lists, content types, event receivers, feature activation events, custom workflow actions, and InfoPath business logic.

The boundary of a sandboxed solution is the site collection where the solution is deployed. You can access the list and library data within this site collection.

This means that you're prevented from writing to the web front end or accessing external data from web services or line of business systems such as SQL Server. At first, this might seem like a major limitation. You can't access this type of back-end data directly from the sandboxed solution, but you can access the data safely using the external content types of Business Connectivity Services (BCS).

The sandbox only applies to code running on the server—Silverlight and JavaScript applications can access web services or other data if they have permission to do so. For example, if you want to make a call to a web service such as Facebook, you could make a call using Silverlight and interact with SharePoint data using the new SharePoint client object model.

Using a mixture of server-side and client-side code, you can accomplish many of the same tasks with sandboxed solutions that you can with farm solutions.

Sandboxed Web Part

Building a sandboxed solution is the same as building a farm solution. The best way to understand the development process is to walk through the creation of a sandboxed solution using Visual Studio 2010.

Start by opening Visual Studio 2010. You can see in Figure 2 that Visual Studio 2010 has a number of SharePoint project templates built in, and there are templates for both Visual Basic and C#.

You want to build a sandboxed web part solution, so you must start with an empty SharePoint project.

The Visual Web Part project template isn't supported in the solution gallery because it contains a .ascx control that must be deployed to the _layouts directory and deploying controls isn't allowed in any directory in sandboxed solutions. For this example, name the solution SimpleWebPart.

After you click OK, the project wizard will ask you what type of project you're creating and for a path, as shown in Figure 3.

The default is to deploy as a sandboxed solution. It's important that you set the correct path to the local site in this dialog because Visual Studio will use this path to deploy and debug the solution.

If you're unsure, it's a good practice to click the validate button to ensure that Visual Studio can connect to the site using the path you set. There's also a link at the bottom of the dialog to learn more about sandboxed solutions from the help system.

After you click finish, you'll have an empty SharePoint sandboxed solution project. You could press F5 and deploy the project at this point, but you wouldn't see much because it contains no features.

Take a minute to understand what's included in the project, shown in Figure 4.

The empty project contains the standard references you would expect in a .Net project and a reference to Microsoft.SharePoint.dll and Microsoft.SharePoint.Security.dll.

There's a node called Features that's empty and will contain the features of your solution package. There's a package node that contains the SharePoint package information. And finally, there's a default strong name key file called key.snk.

Add a Web Part to the project by choosing Add New Item from the project context menu or by pressing ctrl-shift-A (if you're using the C# profile). Be sure to choose the Web Part item, which Figure 5 shows, not the Visual Web Part item.

The default name of WebPart1 is fine for this walkthrough. Click Add to add the Web Part feature to your package. At this point, Visual Studio creates a feature called Feature1, shown in Figure 6, that contains your Web Part.

It also adds a node for the Web Part that contains the SharePoint Elements.xml file, code file, and the .webpart file. Visual Studio contains a visual package designer that will allow you to manage and organize your SharePoint package without editing any xml files.

You can now add the code for your Web Part in the WebPart1.cs file. This code, shown in Listing 1 is exactly like code that you may have written in the past for farm level solutions.

The code displays a list of the lists that are in the current site in a listbox control. Accessing list data and creating lists are two of the most common tasks for a SharePoint solution, and in a sandboxed solution you can work with lists and libraries just as you would in a farm solution. One of the only restrictions is that you can only access lists and libraries within the site collection where the sandboxed solution is installed.

Once you've written the code, you can easily deploy and debug the code from the Visual Studio IDE. Just like most other Visual Studio projects, pressing F5 will compile and debug the project.

In any SharePoint project, there are a number of steps that occur when you press F5--you can see an example list of SharePoint lists in Figure 7. The steps that Visual Studio takes are extensible and you can control all aspects of the build process.

By default, Visual Studio compiles the project then builds the SharePoint solution package file—this is a standard, compressed cabinet (cab) SharePoint package file with a .wsp extension. Next, because this is a sandboxed solution, Visual Studio will upload the solution package to the Solution Gallery and activate it.

It will attach the debugger to the sandboxed solution worker process, SPUCWorkerProcess.exe, and start the web site in the browser. You may be prompted for confirmation to attach to the worker process, as shown in Figure 8.

Debugging this SharePoint code is exactly the same as any other Visual Studio project. Simply set a breakpoint on the line of code.

The best part about developing sandboxed solutions is that you don't have to learn a new way of doing things. If you've developed in .Net in the past, SharePoint development shouldn't have much of a learning curve, and you'll be up to speed developing on SharePoint, Microsoft's fastest growing development platform.

The Future is Sandboxed

Sandboxed solutions are going to change the way that people think about SharePoint as a development platform. You're going to see an explosion in the number of SharePoint solutions that developers create and deploy.

You'll also see the number of community solutions grow as companies running SharePoint trust that the solutions users are running won't compromise the health of the SharePoint farm.

This article only touches on some of the basics of what you can do in sandboxed solutions from the developer perspective. If you're a farm administrator, the sandbox provides new ways for you to monitor and validate solutions that are running in the farm.

I encourage you to install SharePoint 2010 and read the SDK, and as you build solutions using SharePoint 2010, you should always start with a sandboxed solution. Sandboxed solutions provide a quick and safe development model for creating rich agile business solutions.

_____________

Paul Stubbs is a Microsoft Technical Evangelist for SharePoint and Office. He focuses on information worker development community around SharePoint and Office, Silverlight, and Web 2.0 social networking. Paul has also worked as a Senior Program Manager on the Visual Studio team in Redmond. Visit blogs.msdn.com/pstubbs.