What to do? Farm solution vs Sandbox vs App? Let’s recap for a moment, shall we?
For SharePoint 2010, the SharePoint team introduced an elaborate architecture model for hosting sandboxed solutions, which was provided to offer an attractive alternative to farm solutions. Farm solutions are deployed to the GAC or web app bin folder, and have the potential to destabilize the SharePoint farm. They require IT pros to have a working knowledge of Code Access Security (CAS) if you want to limit and/or understand the capabilities of a farm solution. In real life, this proved to be a challenge.
Sandboxed solutions changed all that. The sandbox is a separate process in which SharePoint solutions (so called sandboxed solutions) run in isolation in the User Code Service, running under a very strict CAS policy that, however, does allow you to make service calls on the client side or full trust proxy calls on the server side. To top it all, there was a sandbox resource limitation mechanism, that allowed IT pros to specify resource throttling settings to prevent sandbox solutions from over expanding server resources. All of a sudden, sandboxed solutions suddenly became so important that almost every authoritative resource gave advice that dictated clearly that you should always develop sandboxed solutions unless forced otherwise. This was probably the most recommended development best practice for SharePoint 2010, and it was logical and sound advice. Or was it?
There’s a new kid in town, the App model. SharePoint Apps can be hosted in an isolated SharePoint site, or separate from the SharePoint farm, either on a dedicated self-hosted application server or in the cloud (Azure). SharePoint Apps then have to leverage the extended and improved client object model to connect back to the SharePoint farm if they want to do some work there (SharePoint server-side code is not allowed/possible for Apps). The major advantages of SharePoint apps are twofold:
The new development best practice is to build SharePoint apps in situations where earlier, you would have chosen to build a sandboxed solution. Remarkably, some earlier advocates of sandboxed solutions have switched views 180 degrees, now claiming that sandboxed solutions obviously were useless from the beginning, since they were not allowed to do anything. That’s quite unfair. Probably, a more correct way of putting it, is that nowadays Microsoft feels that whatever you did with sandboxed solutions can also be done, in a better way, via SharePoint Apps.
When we first learned about SharePoint Apps, they seemed like a logical extension to the existing development options. The fact that sandboxed solutions are now deprecated, surprised us, nevertheless, it’s interesting to do a comparison. It’s still a bit early in the game, as SharePoint 2013 has yet to be released, so this overview is bound to undergo some changes. But for now, here goes:
When to use
Deprecated. Therefore, it’s unadvisable to build new sandboxed solutions.
Best practice. Create apps whenever you can.
Create farm solutions when you can’t do it in an app. See http://www.learningsharepoint.com/2012/07/20/sharepoint-2013-apps-vs-farm-solutions/ for more info.
Server-side code
Runs under a strict CAS policy and is limited in what it can do.
No SharePoint server-code. When apps are hosted in an isolated SharePoint site, no server-code whatsoever is allowed.
Can run full trust code. (Custom CAS policies are not supported in SharePoint 2013. All farm solution code runs in full trust even if it is not deployed to the GAC. Any custom CAS policies are ignored.)
Rickee edited Revision 14. Comment: Corrected mention of custom CAS policies. Support for them was dropped in SP 2013
Richard Harbridge edited Revision 12. Comment: Completed incomplete sentence on farm level solutions - Safety
Margriet Bruggeman edited Revision 11. Comment: removed double list
Ed Price - MSFT edited Revision 6. Comment: The Sandbox column needed more room
Anonymous2232323232 edited Revision 5. Comment: Latest row on Cloud Support switched on-premises and App MarketPlace
Ed Price - MSFT edited Revision 3. Comment: Title casing; added tag
Margriet Bruggeman edited Revision 1. Comment: fixed table
Margriet Bruggeman edited Original. Comment: add
Hello,
Great comparison! But I've got a little question,
Is it official that the sandboxed solutions are deprecated?
I found this topic (www.andrewconnell.com/.../understanding-sharepoint-2013-apps-aka-apps-101.aspx ) where mister Connel says that it's not sure and I didn't find more fresh info about this..)
I love Andrew Connel's blog, it's probably my favorite SharePoint blog, but you have to realize it's not an official source. I'm currently in the process of writing a chapter for the new MS Press SharePoint 2013 Administrator's Companion book about SharePoint Apps, and I have to say the amount of resources that state they are deprecated is overwhelming. So, I assume they reall are. Anyway, after SPC2012 any doubts will be cleared.
Thanks Margriet :) .
Yeah I know that this is not a official one but I found nothing more recent :s.
Wait to have more info with the conference!
Thanks!
Hi
Nice overview. Why does the list appear twice? And there is som missing text in the farm column regarding security.
Hi Margriet, did you get any confirmation on the Sandboxed deprecated-or-not case during SPC ?
I've seen so many MS resources saying its deprecated that that's what I'm assuming. The forthcoming MS Press SharePoint 2013 Administrator's Companion (which will be released in march or so) also states that it's deprecated.
The following flow chart should help for the decision:
www.fiechter.eu/.../Post.aspx