Excerpt from upcoming title: Inside Microsoft SharePoint 2010
Today we’d like to share an excerpt from one of our upcoming books: Inside Microsoft SharePoint 2010, by Ted Pattison, Scott Hillier, an Andrew Connell. We’ll publish this book in July 2010. You can learn more about the book here: https://oreilly.com/catalog/9780735627468/.
The excerpt is an introduction to the topic of “sandboxed solutions.” Enjoy:
Sandboxed Solutions are SharePoint Foundation features that are deployed into a partially-trusted environment referred to as the “sandbox.” The sandbox is designed to bring greater stability to the SharePoint farm by restricting actions that may cause performance, security or other problems. It does this by limiting the functionality accessible to custom code solutions through the use of code access security (CAS) policies and restricting access to portions of the object-model. The sandbox is a new capability for SharePoint Foundation (SPF) 2010 and represents one of the most-significant platform changes for the developer. Because of the benefits offered by the sandbox, developers should always look to deploy custom code to the sandbox before considering any other option. Therefore, a strong understanding of the sandbox is critical for writing robust SharePoint code.
Prior to SPF2010, the vast majority of custom code had to be deployed to the Global Assembly Cache (GAC). Because of this, developers often operated with full-trust on the SharePoint server to not only call any part of the object model, but to call databases, web services, directories, and more. The one major exception to this rule was web parts; web parts could be deployed to the GAC or to the bin folder under the web application where it would be used. However, web parts in the bin folder were often granted full trust anyway by simply changing the trust level setting in the web.config file to Full. The end result of this situation was that nearly all code in the farm ran with full trust and few SharePoint developers had the need to learn much about CAS restrictions. The drawback of this approach is that the SharePoint farm was occasionally destabilized by custom code. To make matters worse, the offending assembly was often hard to identify.
As an example, consider the case where an intermediate-level SharePoint developer is writing a web part designed to aggregate tasks from many lists for display on a site collection home page. Imagine this developer is unaware of the Microsoft.SharePoint.SPSiteDataQuery object and instead intends to loop through all of the sites in the collection, loop through all of the lists in the site, and finally loop through all of the tasks in a list to create a single view of all tasks in the site collection. Furthermore, the developer intends to elevate privileges with the web part code to ensure programmatic access to the entire site collection. This simple web part could easily destabilize the farm.
Opting to loop through all of the lists and items is a potential disaster because the process of looping will cause entire lists to be loaded into memory. If these lists are large, significant resources could be consumed resulting in performance problems for all users as these resources would then be unavailable for servicing other requests. Elevating privileges is potentially problematic because the code will gain access to all lists and the intermediate developer may be unaware that creating Microsoft.SharePoint.SPSite and Microsoft.SharePoint.SPWeb objects without properly disposing of them will lead to memory leaks. If this simple web part is deployed to the GAC, it will have no limitations on the resources it can consume. If the web part is then put on the home page of the portal, it will be hit by potentially thousands of users. It won’t be long before the farm is brought to a standstill due to low-memory availability.
Interestingly, when poorly-written code does destabilize the farm, the developer rarely suffers. This is because the farm has limited mechanisms for identifying the code that is causing the problem. In some cases, there may be information available in the unified logging system (ULS), but often it is just a mysterious performance problem. As a result, the problem generally falls on the IT professionals in charge of running the SharePoint farm. They are the ones who receive a call on Friday night saying that the farm is misbehaving. They are also the least-qualified people to identify and fix the real problem (not due to a lack of anything on their part, but simply due to the fact that they are not the developer who wrote the custom code that is causing the problem). In fact, IT professionals may actually cause further problems by desperately making changes to the farm configuration in an attempt to regain stability. Sometimes such situations become chronic, which results in negative experiences for IT Professionals and end users who begin to question the viability of SharePoint as a platform.
On the other end of the spectrum, experienced SharePoint developers often need access to trusted resources like external databases in order to solve a business problem. These developers may be well aware of CAS limitations, understand the SharePoint object model, and generally create professional solutions. Unnecessarily restricting their custom code would significantly reduce the flexibility of SharePoint as a platform. Therefore, the challenge is one of balancing the agility required to solve business problems against the farm security and stability required of enterprise applications. This is where Sandboxed Solutions come into play.