SharePoint 2007 was a developer platform! But it took a developer with the patience of Job and the intelligence of MIT to deal with the bad development tools that we used to work with in SharePoint 2007. The picture in SharePoint 2010 is a lot better!

NOTE: This article is excerpted fromMicrosoft SharePoint 2010: Building Solutions for SharePoint 2010by Sahil Malik, published by APress, copyright 2010 and is printed with the publisher’s permission.

Visual Studio 2010 right out of the box has fantastic development tools for SharePoint 2010. It includes many project templates that make your SharePoint development a lot easier!

When you start Visual Studio 2010 and create a new SharePoint project, Visual Studio pops open a dialog box shown in Figure 1, which asks you two questions.

Which local site do you want to use for debugging? This is the same machine that you are running SharePoint on. While you may chuckle wondering why Visual Studio has to ask such a silly question. After all, this is always my local machine!! The reality is, sometimes you may have alternate URLs set up even for your local machine, and that may be important in certain development tasks. Secondly, the site collection you intend to debug your code on may not be a root level site collection. Finally, if you have multiple web applications, this tells Visual Studio which W3wp.exe process to attach to for debugging! So, you see, it’s not such a silly question after all, is it?

And as I said, providing the URL tells Visual Studio which web application you will debug your code on, and thus, which W3wp.exe process Visual Studio should attach itself to during debugging, so you as a developer can now create a breakpoint, hit F5, and your breakpoint just hits! Something our fellow .NET developer brethren have been doing since 2001 is now finally available out of the box to SharePoint developers.

That was my marketing side talking! Yes, in simplistic scenarios, F5 debugging will work. However, the reality is, in many situations you will find yourself attaching to processes. For instance, sometimes your code may not run inside W3wp.exe. It may run under a separate EXE called SPUserCodeService.exe. That would be a sandboxed solution which is what this article is mostly about.

Now let me address the second question that Visual Studio wishes you to answer. It asks if you intend to create a sandboxed solution or a farm solution.

A farm solution is what used to be a solution in SharePoint 2007. Basically, it had unfettered rights to your SharePoint farm - it could do anything. Sounds like a good proposition, but this created an immense headache for the two poor farm administrators in your organization who were then expected to somehow review every line of code being deployed to the server. A task they intend to get around to doing right after they solve world peace and hunger. Frankly, it is unreasonable to expect two overtaxed IT Pro people to review every single developer’s code. And since some developers can be really crafty, custom code, while being necessary, is the #1 reason for support issues on SharePoint in general.

So Microsoft came out with the concept of sandboxed solutions, sometimes also referred to as user solutions or user code. Put simply, a sandboxed solution is what runs inside a secure sandbox. It runs inside a separate process from W3wp.exe, and it is protected by a CAS policy, so you no longer have to craft custom CAS policies. Also, in addition to being more secure, it is also easier to monitor.

Being more restricted and thus secure, and being easier to monitor, sandboxed solutions can now be deployed with more confidence. And thus, they are now deployable and can be activated right through the site collection. The Farm Administrator doesn’t even need to be bothered, because he is monitoring the solution anyway.

Sandboxed solutions are awesome! When approaching any development job on SharePoint, you should consider sandboxed solutions because of the following two very good reasons:

1. Secure by default, you should create sandboxed solutions when you can. Creating a farm solution unnecessarily is bad practice. Or, perhaps a better way of saying this is, create farm solutions only when you cannot create a sandboxed solution.
2. You can choose to change your mind later, i.e., change a sandboxed solution to a farm solution or vice versa if you need to.

Let’s dive into the details of sandboxed solutions!

What Is a Sandboxed Solution?

A sandboxed solution is a new concept introduced in SharePoint 2010. A solution, as I mentioned earlier, is how you deploy new custom code to your SharePoint server. Custom code is that essential evil that is impossible to deliver real-world projects without, but also cause the most headaches and effort.

A sandboxed solution is custom code that runs in a safe sandbox. It runs under some standard non-negotiable restrictions, so it can only do certain things and is prevented from doing certain other things. Mostly those certain other things that cause the most headache.

In addition to being restricted to doing only certain things, a sandboxed solution can be monitored by two levels of administrators. The site collection administrator can monitor them through Site Actions -> Site Settings -> Solution Gallery, and the farm administrator can monitor them through central administration on a per-site collection basis.

The farm administrator, in addition to monitoring these sandboxed solutions, can also set limits on the resource allocation to sandboxed solutions on a per-site collection basis using the standard quota mechanism. There are fourteen different metrics that contribute to such resource allocation, and it is done using a points-based system. The farm administrator allocates a certain number of points to a site collection. If any sandboxed solution causes the number of points to jump over the total allocated points, all sandboxed solutions in that site collection are halted until a timer job that runs every 24 hours resets the site collection. Also, if an application that is under the allocated number of points tries to do something naughty like format a drive, the execution is blocked, a certain number of configurable points are charged, and the solution can attempt to do something naughty again (only to be blocked again, and charged more points!). On each of these metrics, the farm administrator has the ability to set an absolute limit of resource points before the execution is halted, or an incremental number of points that are charged, without blocking resource allocation. This is useful since sometimes you want to halt execution and increment resource usage points! But, sometimes you just want to count resource usage points but not halt yet!

I like to think that this level of monitoring is very much like a family cell phone plan. Dad, Mom, Sister, and Son have a pool of 2000 minutes to share. Now if the Son starts calling his girlfriend in Russia a little too much, everyone’s cell phones quit working! Now Dad has to call the phone company and request the entire family plan to be allowed to run, and the offending solution (the Son’s cell phone), can now be blocked from execution. Thus, the farm administrator also has a concept called blocking sandboxed solutions. Certain sandboxed solutions that are known to be troublesome can be blocked by the farm administrator.

Finally, if you have code that is more restricted and better monitored, and less damaging to your server environment in general, you can be more confident when you deploy it. Thus, the biggest advantage of sandboxed solutions is that they can be deployed by the site collection administrator of a site collection, and they are deployed directly into the solution gallery in a site collection-as you have been doing all throughout this chapter. Also, if a sandboxed solution does not deploy an assembly, it can even be deployed by individuals with full control to a site collection. This greatly alleviates the headache of the farm administrator.

Sandbox Solution Architecture and Restrictions

It is clear that sandbox solutions run under certain restrictions! You saw one of those restrictions-being able to make changes to the file system, even during deployment. But it is important to understand the architecture of how sandbox solutions work before we can talk about the specific restrictions. The Sandboxed solutions architecture in SharePoint 2010 revolves around three processes running on the server.

1. The User Code Service, which allows a WFE to participate in the sandbox.
2. The Sandbox worker process, which is the actual process that runs your sandbox code.
3. The Sandbox Worker Process proxy, which is built on the new services infrastructure of SharePoint.

The three processes working in tandem above give you a restricted API from SharePoint, and they tie your code under a CAS policy.

To read more about the details of sandbox solutions architecture and restrictions, please see http://blah.winsmarts.com/2009-12-SharePoint_2010_Sandbox_Solutions__Architecture_and_Restrictions.aspx.

Sandbox Solution Monitoring, Management and Deployment

As you can see, sandbox solutions are inherently secure because they are restricted on what they can and cannot do. Which means, I can be confident that they won’t format my c:\ drive, and that’s a good thing! However, what if someone put the following code block in their sandbox solution?

while (true) { i++;}

The above will chew up CPU resources of your high-end server processors! But, it’s not a security violation is it? Neither is it part of the restricted API! Thus, you need to monitor sandbox solutions and take action if they do something naughty, like the above!

You’ll find management UIs built inside SharePoint 2010 for both the site collection administrator and the farm administrator. Also, there is a rich resource usage infrastructure built into SharePoint that monitors resource usage on 14 different metrics. Table 1 shows the specific metrics monitored in SharePoint 2010 for sandboxed solutions:

To read in-depth about sandbox solution management, please see http://blah.winsmarts.com/2009-12-SharePoint_2010_Sandboxed_Solutions__Monitoring,_Management_and_Deployment.aspx.

Sandbox Solution Validations

Farm administrators can be proactive in deploying solution validators to their farm when a solution is uploaded to a solution gallery. If a solution fails validation, the user sees a suitable message, and their solution cannot be activated.

If a farm administrator adds a validator after solutions have been activated, the validator will be called the next time the solution executes. If a validator is updated, the solutions are validated again the next time they are executed.

Writing a solution validator is as simple as inheriting from the SPSolutionValidator class. To read more about the process of writing, registering, and using a solution validator for sandbox solutions, please see http://blah.winsmarts.com/2009-12-SharePoint_2010_Sandboxed_Solutions__Solution_Validations.aspx.

Sandbox Solutions Full Trust Proxies

Sandbox solutions are great because they restrict the average Joe developer, and they allow the farm administrator to manage and monitor. But sometimes you need to negotiate the boundaries of what a sandbox solution can do! For instance, let’s say your client gives you a crazy requirement that through a sandbox solution, you need to create a file on the disk of the web server! To make things even more interesting, the sandbox solution packages a Web Part, which presents the user with a simple textbox. The file contents will be whatever the user typed into that text box, through a web-based solution, in a sandboxed solution! Yes, it is a crazy requirement, but I am using this only as an extreme example to demonstrate my point!

The solution to this problem is to write a full trust proxy! The obvious question you may have here is, if you can get around the whole notion of sandbox solutions using full trust proxies, then why even bother with sandbox solutions? What is that boundary good for if it can be broken!?

Well, take heart! You want to break your architecture down into two major pieces. You want to deliver the first piece completely using sandbox solutions! For the second piece you’ll build an API using full trust proxies that the sandbox solutions can leverage.

The big idea here is that the architect creates an acceptable API that is available for all sandbox solutions to use! Thus, there is still significant control on what portions of the API are open for access.

To read more about the process of writing a proxy, registering it in SharePoint 2010, and using it in sandbox Web Parts, please see http://blah.winsmarts.com/2009-12-SharePoint_2010_Sandboxed_Solutions__Full_Trust__Proxies.aspx.

Summary

Sandbox solutions are awesome! This is going to be the de facto choice in providing new functionality within SharePoint. In fact, you should not write a farm solution if you can deliver the functionality purely using a sandbox solution!

I am quite certain that all SharePoint developers going forward will write plenty of sandbox solutions. You, as a SharePoint developer, need to master this concept!

Happy SharePointing.