UPDATED! Microsoft has finally come out of their hole and shared!
From the SharePoint dev blog posted 1/14/2014:
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 http://blogs.msdn.com/b/richard_dizeregas_blog/archive/2013/08/01/sharepoint-sandbox-isn-t-dead-usercode-is.aspx. 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 http://social.msdn.microsoft.com/Forums/sharepoint/en-US/e7aac2f8-acd8-486a-bc45-17f0a03c2962/when-to-use-sandbox-solutions-in-sharepoint-2013
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).
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 http://msdn.microsoft.com/en-us/library/ff798382.aspx 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.
Then this wiki http://social.technet.microsoft.com/wiki/contents/articles/13373.sharepoint-2013-what-to-do-farm-solution-vs-sandbox-vs-app.aspx states about when to use Sandbox
Deprecated. Therefore, it’s unadvisable to build new sandboxed solutions
But then I come across http://msdn.microsoft.com/en-us/library/dn268593.aspx 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. http://msdn.microsoft.com/en-us/library/jj163199.aspx 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?