Easy Dynamics Blog

Sandbox Solutions vs. Farm Solutions

Posted by Joseph Davis on Jul 25, 2016 11:00:00 AM

So you want to build a sand castle, but you’re using Sandbox Solutions. Next, the question may come up about Farm solutions. You may ask yourself, "What are the differences?" In this blog post, I'll cover the differences and advantages of Sandbox Solutions vs. Farm Solutions. The goal of this post is to not only introduce you to idea of SandBox Solutions and Farm Solutions but also address the issues associated with each. 

Sandbox Solutions vs. Farm Solutions

Before we get started, let’s establish the differencesSandbox_vs._Farm_Solutions_blog_post_by_Joseph_Davis.png in the two:

  1. In SharePoint, Farm solutions are hosted in the Internet Information Services (IIS) worker process (W3WP.exe).  If a user runs any code in a farm solution, the whole farm will be impacted. If a user deploys or retracts a feature, the whole application pool will get recycled. Refer here for more information here.
  2. Sandbox solutions, which are hosted in the SharePoint user code solution worker process (SPUCWorkerProcess.exe), run code that can only affect the site collection of the solution. Because Sandboxed solutions do not run in the IIS worker process, neither the IIS application pool nor the IIS server must restart.

Long story short, both are necessary evils. Whether you use the solution used by most organizations as the ONLY form of deployment (SharePoint), or you use the solution while you risk breaking your environment and putting your security at risk (Farm), the path you decide is yours. But ultimately, the organization chooses what is best for the outcome in question.

blog subscription for fixes and how-tos CTAEarlier I mentioned that the Sandbox solutions only affect a site collection. Sandbox solutions are limited though. Limitations are going to include no access to elevated privileges which will restrtict acess to SPSecurity, Taxonomy, and issues including reading and writing to the file system. Organizations like to use them in order to protect against bad code or bugs in code. By utilizing this capability, they not only won’t break the server, but also won’t cause the server to slow down. Additionally, the processing involved should run under an involved scope. This literally means that if you write anything that goes wrong, the cause will be "pinned" and the code will be disabled while it's awaiting a fix.

What’s the Catch?

Although Sandbox solutions are useful for organizations who want to restrict overall acess, limitations are going to include: 

  • Elevated privileges are revoked: Sandbox solutions require full trust proxy to include code and decisions that would be taken care of by a farm administrator whether to run the solutuion or not. 
  • No programmatic access to taxonomy is allowed: So we won't be able to do Elevated privileges, which would be useful here.
  •  No Web Application-scoped Features or Farm-scoped Features: If we have 100 site collections, then we must deploy the same sandbox solution to the 100 site collections.

Wait, I Need ULS for That Custom Log

A user can maneuver through this to create a hidden list and then log what would typically be manually logged to that list. In a situation I’ve encountered recently, I created a custom interface that interacted with a custom API that in turn writes to said list. By doing this, I found the issue and avoided it (like we all want to avoid Washington D.C. traffic), almost like using Morse code to users outside the restricted sandbox.

The Wrap-Up

Hopefully you’ll walk away knowing the differences between Farm solutions and Sandbox solutions. These necessary evils have limitations like I discussed. When a sandbox solution is assigned by an organization, you want to do so much more in order to create an application. Sandbox soultions limit a developers ability which, in turn, forces the developer to create shortcuts (or even more difficult solutions to result in the same end product). We want to build that sand castle 500 ft away but you can’t get out of the sandbox! The restrictions can be overcome so people can look outside that box to build that sand castle! End of story, we have so many limitations, but we also have a beautiful sand castle.


What other advantages and disadvantages have you found using sandbox solutions for SharePoint in your work? Share your wisdom with us in a comment below!

Found this blog post useful? Make yourself comfortable and check out our blog home page to explore other technologies we use on a daily basis and the fixes we've solved in our day to day work. To make your life easier, subscribe to our blog to get instant updates sent straight to your inbox:

Subscribe to Blog at Easy Dynamics for Fixes and How-To's

Topics: SharePoint, Web Application, Web Development, Programmable Infrastructure, Sandbox

Easy Dynamics: The SharePoint Experts

We are a leading SharePoint Services and Solutions shop located in Washington, DC. 

Thanks for coming to our blog! Here you will find relevant news and information about the technologies we use and other things we find interesting. Want to know more about who we work with? Or our first commercially available product, EasyBox

You can find links to all of these things and more right from this page. Enjoy reading!

Subscribe to Email Updates