|This article is part of a series of posts on the App model:
This is a question I continually get as Microsoft continually push you to write Apps over Solutions…remember in SharePoint 2010 when they pushed Sandboxed Solutions over Full-Trust Solutions…well in SharePoint 2013 that push has now moved to Apps. I have been presenting a session on my thoughts on this which I encourage you to watch, but I’ve written it all up below too with more up to date information.
The reasons that Microsoft are pushing Apps over Solutions are below with my thoughts on each point:
- Cloud ready – the biggest push for Apps is so you can move to Office 365…right now if you’re using Full-Trust Solutions you can’t move. They’ve changed their tune on Sandboxed Solutions too now and saying Apps all the way.
- Development Environment – You can now write Apps without any SharePoint server running on the operating system where you have Visual Studio installed. Full-Trust Solutions require this.
- App Catalog / Office store benefits – can side load to Tenant Wide App Catalog or publish to the store to make your customizations available. This allows you to pick who can actually add these business solutions to your tenant as you can configure the visibility in ways you couldn’t with Full-Trust Solution Packages and Features. Sure you can do this with Sandboxed, but this is on another level.
- App Impersonation – when calling the Client API you can impersonate the App rather than impersonate the user which is powerful for a lot of business solutions
- Managed Code – you can still write managed code (C#/VB.NET) in Auto-hosted or Provider-hosted apps against the Client API, so for Developers used to writing “real code” you still can.
- Developer Reach – Allows you to write under any web application framework (LAMP, ASP.NET MVC, JAVA, HTML/JS…) as your customizations sit in IFRAMES on SharePoint pages and call Client API. Although you STILL need Visual Studio which I believe will reduce reaching all of these “Web Developers” that Microsoft keeps touting that can now write apps for SharePoint.
(UPDATE 16Oct: I’m waiting for more information on Microsoft as you don’t *need* Visual Studio to build the App Package)
- Scalability – takes the load off of the SharePoint Farm to either the client side or server side on a non standard web application server. It also means you can scale up wherever you are running your code without having to scale the SharePoint Farm (obviously you cant do this in Office 365 anyway, but could do On-Premises). I’m not sure I believe this is relevant for On-Premises organizations building business solutions just for themselves, I believe this is an issue if you build for multiple tenants like an ISV or SI. If you need to scale your app in your own On-Premises Farm, you probably need to scale your SharePoint server too, especially if its calling SharePoint Client API a lot. This clearly benefits Microsoft Office 365 operations a lot regardless.
- App Versions – unlike the Solution package that never had a version (features did) the App packages do have a version. This allows you to much easier be able to manage versioning of your business solutions in each environment in a standardized way.
When do apps not make sense?
A lot of the push back I’m seeing to Apps is a lot of organizations are still running SharePoint On-Premises with Full-Trust solutions specifically for their organization who have no intention to go to the cloud and have no need to leverage the App Model to build customizations. They also don’t see the benefit in investing in “migrating” their code from Solutions to Apps.
There are also some scenarios where you simply can’t use Apps or impede you too much that I have come across:
- Server Side Object Model breadth - the SSOM has a lot more properties, methods and hooks into SharePoint than all of the Client APIs put together (CSOM, REST, ASMX, RPC etc.).
- Client API performance – the Client API’s are still slower than running SSOM.
- Site collection scoped – much like Sandboxed Solutions, Apps are scoped at Site Collection for deployment and cannot call Client API outside of the Site Collection they were added to.
- Branding (master pages, application pages) – there are “workarounds” to deploy branding in Apps, but the reality is you need to use Sandboxed Solutions.
- Delegate controls – not being able to use Delegate controls really restricts clean ways of overriding out of the box UI in SharePoint.
- Custom Activities in Workflow - the new SharePoint 2013 Workflows don’t allow for reusable actions like the old SharePoint 2010 Workflows that can be deployed with Solution Model.
- Non OData BCS Models – In-memory BCS in Apps only supports OData.
- Connected ASP.NET Web Parts – App Parts cannot be connected, so you’d be building a bus layer yourself under the covers for these to talk to each other…which is extremely hard if App Parts are part of different Apps.
- _Layouts artifacts – not being able to deploy to the file system can cause issues for some implementations over deploying them as Site Pages instead in the Content Database.
- Custom Field Types – custom field types are a popular way to extend lists but require Full-Trust Solutions. David Mann has written a post on an alternative to this.
- Application Pages – Apps can have full immersive pages that inherit style sheets but can’t inherit master pages and page layouts like Application Pages. This gives you the true immersive SharePoint experience.
- Service Applications – I only ever saw two Service Application ever implemented since these were made available in SharePoint 2010 and that was Newsgators product and NothingButSharePoint.com social capabilities.
- Timer Jobs – these have always been very unreliable compared to Windows services, so this isn’t a big deal, but there are a lot of organizations that have built these and want to continue to leverage them.
The traditional Solution model approach is still 100% viable for On-Premises customers and is a lot more polished than the App model. Every bodies skill sets are still well and truly in this area as true Enterprise Development also and I don’t see many changing soon primarily due to this and the following…
Remember that this is the first version (1.0) of Apps released by Microsoft and there are a lot of gaps as expected. Microsoft will certainly fill these gaps over time, please go give your feedback on these to let the Product Team know what is important to you and your organization.
The list below are gaps that I personally feel affect both my organization as an ISV but also I’m hearing affect organization building business solutions for themselves either On-Premises or Online.
- No OAuth On-Premises – There is no support for OAuth On-Premises so you baseline is to use S2S (Full Trust) configuration which is not ideal and means you have to write your Apps in two different ways for authorization. There are ways of getting OAuth working On-Premises in a Hybrid way but again this is not easily achieved by the average organization.
- No migration path – yep…there is no way to open up your Sandboxed Solution Project and convert it to an App Project in Visual Studio.
- On-Premises installation is complex - At AvePoint, we have two apps in the Store which are very easy to add to Office 365. Getting Apps configured and running On-Premises is not simple and troubleshooting if one step fails is very hard.
- Office 365 ULS logs – It is extremely tricky to debug in Office 365, if this is really the answer for the future…Microsoft need to think of a way of handling multi-tenant diagnostic logging as a platform.
- Permissions troubleshooting – a lot of the times your App will have to request permissions more than just Contribute and ask for Full Control for simple things which may deter Users from “Trusting” it and adding to their Site Collection.
- No user controls – there is no People Picker, Site Picker, Document Uploader controls that you can re-use if you go Auto-Hosted or Provider-Hosted.
- Update Apps Individually – When you deploy a new version of the App to the App Catalog or Store, each App instance requires you to update it individually. This causes all sorts of issues with Provider hosted Apps where you now have to cater for App Instances of different versions and your Provider Hosted code calling back up to the App Web and assuming a particular version instance.
- Can’t add App Parts on Add of App – When a User adds an App to their Site, unfortunately there is no hooks to add the App Part to the homepage of the Site. This paradigm is well practiced in Windows 8, Windows Phone 8 and iOS etc.
- Office 365 P-SKU – Apps that request Tenant level permissions cannot be deployed to P-SKU Office 365 Tenants
- One instance per site – you cannot add the App more than once to a site, unlike a Document Library where you can.
- Auto-hosted – Auto-hosted is only available in Office 365, and right now aren’t supported in the Store.
- SharePoint Designer – can’t connect to an App …maybe the sign this thing is dieing for good.
What should I do?
It really depends on what your current approach is to customizing SharePoint right now. Here are my thoughts depending on where you are at:
Not on SharePoint 2013
Clearly if you’re not on SharePoint 2013 and still on SharePoint 2010…or worse SharePoint 2007 or 2003 (god help you) then your customization routes are harder as App don’t work here…and you’re “stuck” with the Solution Model (except in 2003 where you are in hacker land). In terms of Full-Trust Solutions vs Sandboxed Solutions…well Sandboxed Solutions have their limitations that force you to use Full-Trust at points, but my guidance would be where you can use Declarative Sandboxed to at least be Cloud Ready over not being.
Heavy Sandboxed Solutions Server Side Object Model house
Managed Code Sandboxed Solutions are deprecated now so technically y0u really shouldn’t be writing any C# or VB.NET in Sandboxed Solutions anymore. Microsoft won’t pull the plug anytime soon on these not working in Office 365, but its a warning that there are no improvements in this area coming. Net new business solutions should really be written in either Declarative Sandboxed Solutions or Apps. By moving to Declarative Sandboxed Solutions you are somewhat forcing yourself to use Client API which helps with the movement. The discussion of Declarative Sandboxed Solutions and Apps really comes down to whether you need any of the new features available in Apps and if not, there is no reason to really move to Apps and totally acceptable.
Heavy Full-Trust Solutions Server Side Object Model house
If you really are a heavy Managed Code shop On-Premises now, then there is going to be very little of what you’ve written that can be migrated to new Apps. It may be worth where you can using Declarative Sandboxed Solutions and start to isolate the SSOM code to gain an idea of how much can’t be moved. What I would recommend in this instance is that you start using the Client API wherever you can over the Server Side API even when using Managed Code (C#/VB.NET). This will make it easier for you to “migrate” to the App Model when you upgrade to SharePoint 2013. Remember that Provider Hosted Apps still mean you can write C#/VB.NET code using the Client API…so it’d be a lot of cutting and pasting between Visual Studio projects as there is no tool to help here.
Microsoft will not be investing in any tooling around Solution Model in the future, so all the new shiny add-ons to Visual Studio etc. will only be coming to the Apps Model approach. With this in mind and the fact that eventually you will have to switch as they possibly start announcing deprecation of Full-Trust Solutions and Declarative Sandbox Solutions over the next five years, so best start getting used to the Client API!
What areas are still grey?
Some of the unanswered questions around Apps are around how you deal with things like when to use App web vs Parent Web (ghetto web), what can you put in SharePoint, CSOM vs REST, Versioning Apps, ALM in general, Unit Testing in the App Model. I will cover those in upcoming articles.
Will Microsoft change their mind?
Well they are on their third striker after trying with Full-Trust Solutions, moving to Sandboxed Solutions and now onto the App Model. I don’t believe they will ever deprecate the App Model…I believe they will continue to improve this model…it has the foundations to be a success once they iron out these kinks and listen to feedback!
This interview by Scott Hanselman who is a very highly respected and powerful guy inside Microsoft Development with Keenan Newton (former SharePoint Product team) asks him about why SharePoint Apps are valuable to Web Developers.
I hope you found this useful and I’d love to hear your thoughts in the comments on this post. Microsoft have their own official take on this also, have a read and let me know what you think
- [16 Oct] Thanks to Chris Givens (@givenscj) for his feedback on the article, I reworded a few sentences to clarify what I meant by my statement.
Also thank you to Spencer Harbar (@harbars) for suggesting that I make the article clearer that these are my opinions rather than fact in a lot of cases throughout this discussion.
Nik Patel also has a great document that compares in a matrix which is extremely useful too.