John Underwood is a Technical Evangelist at ThreeWill. He has nearly thirty years of software development experience. He is an experienced technical instructor with superior presentation skills and is proficient in delivering standard curriculum as well as developing and delivering custom curriculum.
“We vs. They.” “Us vs. Them.” These phrases instantly bring vivid mental images to mind.
As developers, we probably have some image of who “they” are when it comes to programming. Maybe it’s a customer that simply has unrealistic expectations; maybe it’s a vendor that’s letting us down; or, perhaps it’s the administrators that manage the servers where we deploy our code.
When it comes to developers and administrators their respective missions could be summarized as follows:
- Developers author solutions that solve problems. They get yelled at if they can’t solve these problems in a timely fashion.
- Administrators maintain servers that are used by everyone. They get yelled at if these servers crash or perform poorly.
Even if both groups have the purest of motives the execution of their jobs will naturally put them at odds. In the authoring of solutions, developers will write code that draws on precious server resources; on occasion they may even author defective code that destabilizes a server. In protecting their servers, however, administrators may turn away legitimate code that would benefit the company for fear of the potential impact. This division between groups can be magnified when operating in a multi-tenant environment. After all, an administrator simply cannot allow code from one customer to draw away resources or corrupt data for other paying customers in the same environment.
This relationship is further complicated by the presence of users or paying customers. Ultimately the customer wants it all – an application that perfectly meets their needs, takes less than a second to accomplish any task, and runs on a server that never goes down.
So, how can these two well-meaning groups get along?
In the case of SharePoint 2010, the answer comes in the form of Sandboxed Solutions. As the name implies, a Sandboxed Solution is a SharePoint solution that is authored by a developer, but deployed in such a way that there is some limit to what it can do. Here are some key concepts of Sandboxed Solutions:
- Code may only access a subset of the SharePoint API. By limiting the functions that may be called, a Sandboxed Solution can prevent certain kinds of errors or failures.
- Code runs within its own AppDomain, meaning that it is isolated from other custom code and from SharePoint itself.
- No touching the file system of the server! Anything that would require deploying files below the “SharePoint Root” is forbidden.
- Workflows are forbidden (ouch, that one hurts).
- A “trap door” of sorts exists in the form of a Full Trust Proxy; basically this is an assembly that can make unrestricted calls on behalf of the Sandboxed Solution.
- Deployed code can be throttled by various quotas. For each resource that it uses, a certain number of points are tallied. If the points charged for a particular solution exceed a daily limit, then the solution is shut down for the remainder of the day.
- Solutions are uploaded by the site collection owner, not administrators. This provides the benefit of reduced burden on an already overtaxed IT staff (but also provides the risk that a site collection owner would upload a poorly performing or even malicious solution).
I’ve read some blog posts from respected SharePoint developers that panned Sandboxed Solutions as a bad idea that would inevitably lead to inappropriate workarounds. While there’s probably some truth in that, I think it misses the spirit of compromise that is inherent in the Sandboxed Solution. The definition of compromise is that neither side gets exactly what they want. Administrators do still take on some risk, but with a set of tools for minimizing the impact of that risk. Developers have to learn to treat server resources as precious (something we don’t always do) and educate customers on what can and cannot be done within the confines of the sandbox.
- This video from Andrew Connell provides a nice overview.
- CKSDEV (a must-have for any SharePoint 2010 developer) includes tools for writing full-trust proxies and ensuring that code written for the sandbox doesn’t attempt to call any restricted APIs.
Additionally, if you’re new to SharePoint development and are looking for opportunities to learn about Sandboxed Solutions as well as many other aspects of SharePoint 2010 development then check out ThreeWill’s SharePoint 2010 Developer Bootcamp. It’s a great way to jump-start your SharePoint developer journey.