Skip to content

SharePoint 2013 Apps vs. SharePoint 2010 Sandbox Solutions: The same old thing with a new name?

by on December 20, 2012

Sandbox Solutions

  1. Allow you to execute code in a relatively safe method (the sandbox)
  2. Scoped to the site collection
  3. Introduced in SharePoint 2010
  4. Will be deprecated in 2013 in favor of APPS
  5. Functionality will exist in 2013 for backwards compatibility
  6. It is recommended that any new solutions use the App model
  7. It appears as though the Design Manager in 2013 is actually based on the Sandbox solution model
  8. Sandbox solutions have access to a limited subset of server-side API
  9. Blocked from making external DB or web service (WSDL) calls

Farm Solutions

  1. Also continue to be a viable option in SP 2013
  2. Fully Trusted solution (runs with full trust and deployed on the server)
  3. Not possible with hosted deployments, such as SP O365
  4. Scoped to the Farm (though can be programmed to be more specific)
  5. Have the greatest level of flexibility and also the greatest possibility for things to go wrong in a way you really don’t want to explain to your boss ^_^

Apps

  1. Allow use of a separate application server outside of the SP Farm (this means the farm should not be affected by poorly build custom or third party apps if set up properly)
  2. Introduced in SharePoint 3013 to replace (?) sandbox solution model
  3. Requires setup of an additional server which may be burdensome to a small business or small SharePoint implementation
  4. Does not have any access to the server-side API – all code runs on the client side or an external application server and connects via the SP API (rest, etc.)
  5. There are 3 types of apps: SharePoint Hosted (app is in its own AppWeb on SharePoint and must run within that site in the browser), Self or Developer hosted (can use any framework on any infrastructure and is external to SharePoint, depending on what the developer chooses to work with), and Azure hosted (currently just for O365, cloud based)
  6. Microsoft’s way of making you get your code out of SharePoint to help streamline and get rid of external issues with the upgrade process
  7. Apps are isolated and cannot interact by being installed on an AppWeb on a unique domain to avoid malicious scripting
  8. Can get them through the Corporate (Company specific) or Public (Think Apps Store from Apple) Marketplaces.
  9. Apps have 3 experience options: Immersive (take over the page), Part (appears within the page as with a Web Part), Custom Action (exposed as ribbon control, menu item, or in some other manner of your devising)
  10. Apps can be scoped to the Web (exist only wAithin the AppWeb), or to the Tenant (will connect to a larger service based on multi-tenant model of architecture)

Conclusion

All options are still viable.

The question is, what to you want to do and what kind of permissions do you want to grant to a custom app? Do you want to sell it in the Microsoft App store? Do you need a farm solution or is it just a passing want from someone in upper management who doesn’t really under stand all the implications?

In the end, my advice is Choose Wisely!

Advertisements
Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: