SharePoint 2013 Sandbox Solutions: Declarative or User Code, what’s dead really?

UPDATED! Microsoft has finally come out of their hole and shared!

From the SharePoint dev blog posted 1/14/2014:

While developing sandboxed solutions that contain only declarative markup and JavaScript — which we call no-code sandboxed solutions (NCSS) — is still viable, we have deprecated the use of custom managed code within the sandboxed solution. We have introduced the new SharePoint app model as a replacement to those scenarios that required the use of managed code. The app model decouples the SharePoint core product from the app runtime, and this enables much more flexibility and gives you the ability to run the code in the environment of your choice. We realize that our customers have made investments in coded sandboxed solutions and we will phase them out responsibly. Existing coded sandboxed solutions will continue to work in on-premises SharePoint farms for the foreseeable future. Given the dynamic nature of online services, we will determine support needs for coded sandboxed solutions in SharePoint Online based on customer demand. NCSSs continue to be supported. All future investments will go to making the new SharePoint app model richer and more powerful. Accordingly, we recommend that all new development should use the new app model whenever possible. In scenarios where you have to develop a farm solution or coded sandboxed solution, we recommend that you design it so that it can easily evolve toward a more loosely coupled development model.  [emphasis added]

The remainder of this post is what I wrote prior to the above being shared. I’m going to keep it for two reasons: 1) I was right :-p and 2) it took me a good amount of effort to write it and collect all the references. I’m keeping it!

Originally written 9/12/2013:

What’s the deal with Sandbox Solutions in SharePoint 2013?

I’ve read the Nth blog post on the topic, with the latest being Richard’s post He states:

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.

And Waldek Mastykarz, an MVP I’ve come to respect, stated in MSDN forum

My suggestion would be that whenever you need to provision some resources to your Site Collection or Site you would use a Sandboxed Solution. As long as you avoid writing code and stick to declarative assets you should be okay

This has been the general sentiment throughout the web, and everyone tends to agree. I’m not replying to Richard or Waldek directly, I’m just using them as examples ;).

The word on the street: You can create sandbox solutions in SharePoint 2013, however they cannot contain server-side code; you can only create objects via declarative methods (XAML).

As a consultant, I want to back up my claims to my customers with MS fact, which usually comes in form of TechNet, MSDN or KB articles, or justify decisions based on best practices and industry standards, rarely is it a “just trust me” situation. Sadly, I think this topic falls into the latter 2 categories. I want to find documentation proving it, and since everyone else stating the above hasn’t provided such documentation, I went hunting. Sadly, it’s not as clear as I had hoped.

What does deprecated mean? The deprecation of sandbox solutions means that SharePoint 2013 will allow sandbox solutions, even with server-side code, for the sake of being backwards compatible. When something deprecates, chances are it’ll be removed in a coming version, so upgrade it (to Apps). states

SharePoint sandboxed solutions are deprecated in SharePoint 2013 in favor of developing apps for SharePoint, but sandboxed solutions can still be installed to site collections on SharePoint 2013.

Eh? It’s deprecated but it can still be installed. But what can we do in a sandbox solution? Or is this purely for being backwards compatible? Clear as mud.

Shortly after the above statement, the page actually sends users to a SharePoint 2010 page on farm solutions. Ok, great, we can assume what is doable in a SP2010 farm solution is also doable in a SP2013 farm solution. However, nothing on sandbox solutions. Should I assume the same for sandbox solutions? I came across but this is obviously for SharePoint 2010 sandbox solutions, or is it for SP2013 too, since they sent us to a SP2010 farm solution page.

[getting dizzy]

Then this wiki states about when to use Sandbox

Deprecated. Therefore, it’s unadvisable to build new sandboxed solutions

But then I come across stating

Throughout this section, we will focus on full-trust code (SharePoint solutions) instead of partial-trust code (sandboxed solutions). Partial-trust user code is deprecated as of SharePoint 2013. If you are looking at partial-trust code, you should consider writing an app instead.

Huh, that’s pretty clear, other than it’s hidden, about half way down the page under Factors to consider. So the partial-trust code is not supported, what about declarative? Is the lack of including it stating it’s still supported?

Digging in deeper, I start to find other articles which don’t say sandbox directly, but imply. talks about creating workflows for SP2013 in Visual Studio. When it discusses deployment of the workflow:

Create a SharePoint solution package (.wsp) file and deploy the solution package to the site (SPWeb).

That’s a sandbox solution alright. It even goes into debugging Visual Studio workflows on SharePoint Online, so it definitely is not a farm solution. But sadly, everything is around workflows.

I can’t find a SharePoint 2013 reference for declaring other object types, which we are assuming is supported like web templates, lists, libraries, etc. That’s all I could find, did I miss something?

What’s my decision?

I will agree with the “industry standard” of server-side code is not supported, but anything that can be done via declarative XAML is supported in Sandbox Solutions (lists, content types, custom actions, etc). I wish Microsoft would come out and say it, clearly.

What do you think?

10 thoughts on “SharePoint 2013 Sandbox Solutions: Declarative or User Code, what’s dead really?

Add yours

  1. MS have lost the plot. Going from C# server side code to JQuery client side is a bad move for so many reasons.

  2. Would absolutely love that!!! As David correctly mentioned it is right now more of a “trust me on this” situation without any “clear” official documentation around

  3. David,

    Both Richard and Waldek are correct. Microsoft is working to update the MSDN documentation to indicate more clearly that declarative CAML in Sandboxed Solutions is supported but User Code running in the Sandboxed Code Service (aka – SPUCHostService.exe) is deprecated.

Leave a Reply

Up ↑

%d bloggers like this: