Sandboxed Solutions - Who is Sharing My Process Space?

I recently ran into an interesting scenario with SharePoint 2010 Sandboxed Solutions while working a customer engagement.  While your scenario is not likely to be exactly like my customer’s, the underlying behavior of the Sandbox could potentially lead to similar symptoms.  Hopefully, this post saves you some troubleshooting time.

In my scenario, the customer had two web applications in a SharePoint 2010 farm.  WebApp1 had the SharePoint “Enterprise” features enabled at the web application level.  WebApp2 had only the “Standard” features enabled.  Since the Sandbox is enabled at the farm level, both web applications had the ability to deploy a Sandboxed solution.  The same Sandboxed solution was deployed to a site collection in both WebApp1 and WebApp2.

We were troubleshooting an end-user’s issue with a simple Hello-World-like solution and were getting sporadic failures in the “Standard” web application.  The solution worked 100% of the time in the “Enterprise” web application.  This behavior, combined with ULS entries referring to the inability to load an assembly, pointed to a coding issue in which the solution creator was referencing an “Enterprise” feature.  That was all well and good, but it didn’t seem to fit the pattern of sporadic success in the “Standard” application.

The cause of our sporadic success in the “Standard” web application was an underlying design construct in the Sandbox.  The Sandbox allows processes to share an app domain, which means that one user could initiate a solution and a second user to run the solution within the same app domain.  So why would that cause a solution that references an “Enterprise” feature to sporadically work in a web application that only allows the “Standard” features?  Glad you ask.

Consider this scenario:

User1 visits a page in the “Enterprise” web application (WebApp1). The page is using a web part that is part of a Sandboxed solution, so the user code host process spins up an app domain, loads the appropriate
assemblies, and the web part renders. Immediately afterward, User2 visits a page in the “Standard” web application (WebApp2) that also uses the web part from the Sandboxed solution. In this scenario, the “Standard” user will have sporadic success and here is why.

When the call is made to the user code host to initialize the app domain, the Sandbox checks to see if an app domain for that solution is already loaded.  If it is, the existing app domain is reused instead of creating a new app domain.  If the app domain does not exist (either it was terminated or another server is handling the Sandbox request), a new app domain is created.  This “reuse” can lead to sporadic and unpredictable behavior in your Sandboxed solution.  In our case, the sporadic successes in the “Standard” web application resulted when an app domain created by the User1 in the “Enterprise” web application was reused by User2 in the “Standard” web application.  This sporadic behavior could have any number of “flavors”, so just beware that app domains can be (and are) reused by Sandboxed solutions.