SharePoint Sandbox isn’t Dead…UserCode is


With the introduction of apps for SharePoint, many have speculated that sandbox solutions are dead/deprecated.  This is accurate for solutions containing assemblies running on the Sandboxed Code Service (aka – SPUCHostService.exe).  However, declarative solutions are very much still in play and widely used internally by SharePoint (ex: Web Templates and Design Manager).  A declarative .wsp package (one containing no assemblies) is a powerful way to provision elements into the host web.  So don’t be afraid to leverage the solutions gallery as long as your .wsp packages don’t contain code.

If your solution contains code and a farm solution isn’t an option (read: SharePoint Online), you might consider an approach I outlined in my recent post on App Approaches for Common SharePoint Customizations.  In it, I discussed the use of app installed remote events to provision elements in the host web.  This pattern is generally discouraged, as apps for SharePoint should uninstall cleanly (hence the reason for an app web).  However, it is appropriate for internal apps (not marketplace apps) containing programming logic and host web dependencies.  The app model should not be confused as a deployment mechanism, so if your solution doesn’t have code…consider the solution gallery.

Comments (11)

  1. Wayne G says:

    Thanks for promoting this. I think it's important for SharePoint developers to know there are still options other than the app model that will keep your environment clean.

  2. Chris OBrien says:

    Hi Richard,

    Despite the "deprecated" tag, the idea of it still being valid to use sandboxed solutions for declarative provisioning is how I interpreted things too. However, in terms of sandboxed *code* I'm yet to find a reference on TechNet/MSDN (as of August 2013) which definitively says that code in the sandbox should be avoided. Or even better, something which backs up the assertion that declarative XML is OK, but code should be avoided. Can you point to any public documentation along these lines?

    Thanks,

    Chris.

  3. Martin Hatch says:

    I agree with Chris .. there was a "deprecated in favour of apps" statement on MSDN but nothing in TechNet says anything of the sort.

    I think it was more of a mind-set shift from Sandbox Solutions towards Apps .. but there are still so many scenarios in which apps simply don't cut it, and Sandbox Solutions (even with code) is desirable

  4. The big problem is that remote event receivers can be difficult to set up and in a lot of cases "wasted computing resource".  For example: Most people want to perform something on a declarative basis (copy a file to a library, or create a library lets say) on the event a site or list is created within a site collection.

    Having to create an auto hosted or provider hosted app in order to achieve this when it is something which is internal just seems like overkill.  The best part of this is through site creation.  Now I have seen the blog where a provider hosted app with Tenant Owner privileges can create sites on site collections and can be used for site provisioning within a tenant however it is not clear if there are any issues I have personally with having an app run as tenant admin to which people on low privilege have access and that code runs in the client.

    A sandbox solution which performs this is perfect because the logic is hidden from the end user and site creation works as per any SharePoint 2013 documentation and would be intuitive.

    As long as this is something that can be done in the near future and if not replaced with something of equal functionality then I think this move is fine.

  5. It is not "speculation" that sandboxed solutions are deprecated. Microsoft announced that over a year ago: msdn.microsoft.com/…/jj163114.aspx

    Also, no exception is made for declarative solutions. So what you are saying in this post is contrary to MS's official policy.

  6. Fabian Williams says:

    I am actively trying to get some insights and guidance (official guidance) on this topic. Its all well and good that we CAN do this, but the fear is what happens if MS decides to tell us, …hey we are not supporting this, we warned you.. its deprecated.  I agree Richard to you arguments, and I personally have done what you suggested. But when you are dealing with paying clients, its helpful to get the official doctrine. 🙂 u know what i mean,.

  7. Hi Richard,

    I've quoted you in my blog post, davidlozzi.com/…/sharepoint-2013-sandbox-solutions-declarative-or-user-code-whats-dead-really. It's kind of a reply/repost/venting about this whole situation.

    Thanks!

  8. Eric says:

    I noticed that the Design Manager is mentioned but its extremely difficult to deploy and publish (aka have SharePoint auto-generate the needed JS files) in a solution  without simple logic that makes a dummy update to the HTML files. Would we be able to use feature receivers in Sandbox solutions or does that count under UserCode?

  9. Stefan Bauer says:

    Wonder if someone ever tried to upload sandbox solution from an app.

    Thank you very much make more things clear.

  10. hhtech1 says:

    Localization is a major issue now. We would like to continue to use no-code sandbox solutions to deploy content types, lists, custom actions etc. To localize these, we could use satellite assemblies. But, will the satellite assemblies in sandbox solutions be deprecated as well? If so, we essentially have no localization mechanism at all (except JS localization during page load which is really…).

  11. Daniel Staroste says:

    @hhtech1: please can you explain how do you access satellite assemblies in declarative xml?

    thx