This is part one of a four part series, focusing on transforming your solutions to the new SharePoint App model. In this post I am focusing on ‘Readiness’.
I still recall how I “deployed” my first SharePoint 2003 “solution” with the help of batch files and manually modifying the web.config. Quite crazy if I think about it now and you guess right, it was a pain. I wish I could say that I didn’t know better and needed the money but sadly this is how SharePoint development looked like these days.
Thankfully in 2007, Microsoft introduced full trust farm solutions in SharePoint 2007. It was a huge improvement for SharePoint developers, empowering them with new ways to create customizations. Still, the provided tooling in Visual Studio was either awful or non-existent. To do serious development you had to rely on add-ons like the WSPBuilder (by Carsten Keutmann) or the SharePoint Software Factory (developed by my colleague Torsten Mandelkow and myself).
The farm solutions however have disadvantages in terms of security, manageability and performance, which Microsoft tried to fix with SharePoint 2010 and sandboxed solutions. These too were far from perfect. Fast forward to the present day and we have the latest innovation:
The SharePoint App model.
Microsoft has committed considerable time and resources to creating a new development model that is supposed to solve all the problems of the previous attempts, is manageable and scalable in a large hosted environment like Office365, uses standard web technologies, and will last for the long term. Even though the App model seemed to be widely rejected by developers when it was released with SharePoint 2013, considered to be the next (now deprecated) sandboxed solutions with a limited API compared to the server side object model, it now looks like it has finally convinced the majority of developers that it is the only future-proof way to customize SharePoint. So I guess we all can agree now that
Apps are here to stay!
This series of four posts will focus on how to transform your existing solutions to the new SharePoint App model.
This post focuses on ‘Readiness’. Later posts will look at:
- Assessment and planning
- Development and Testing
- Deployment
Vesa Juvonen and Steve Walker, both Senior Program Managers at Microsoft and well-known public speakers promoting the transformation to the App Model, recently held a Virtual Training Academy session about this topic, which you can access for free here. During this training they also featured our SPCAF tool and its Migration Assessment report, and I will be referencing their best practice advice as we go along. I really recommend you to check out the training, in conjunction with this post series.
Upfront I think it is important to say moving to the SharePoint app model is not only a technical transition. Neither a 1:1 mapping of SharePoint artifacts between the two models nor an automated migration is possible. Hence it also requires a new way of looking at requirements from a business point of view. I will focus on the technical side of things, but as we go along it will become clear how business requirements need to be aligned.
Multiple App types
When getting ready to tackle the App model there are a few basics to understand. The first is the different types of Apps permitted by the model. There are three:
- Immersive full page: The App is displayed full screen.
- App part: The App is displayed in a web part, and can be placed on any SharePoint page.
- Custom UI action: The App deploys a custom action to for example an existing library in the SharePoint site.
Each App obviously has its own uses, and generally the UI requirements of your functionality will play a large part in which one to use:
- An Immersive App doesn’t even need to let the user know it is running on SharePoint
- An App part is the closest thing to a webpart, in old terminology, and is useful for building widgets that occupy part of a page.
- A custom UI action is geared more to tweaking the out of the box interface i.e. adding options to existing menus.
As the SharePoint app model has been around some time by now already, you can find plenty of resources explaining the differences in details. A good place to start is the Office Dev Center on MSDN, which is constantly updated and extended with new articles and samples.
No more farm solutions, big App advantages
No matter the specific App type, all have several advantages compared to the old farm solutions model. The biggest is they are future proof, customizations will not break when a new SharePoint version is installed (which can happen basically any time on SharePoint Online). This is in a large part down to how the App model is constructed and the technology used
There are two ways to build a specific App, and it is important upfront to be ready and know which to use:
SharePoint hosted Apps
A SharePoint hosted App is a set of HTML, JavaScript, and CSS files and these files are hosted inside the SharePoint site. It does not contain server side code, it can only contain JavaScript code to talk to SharePoint. It is the easiest option to begin with, as it does not require additional hardware or hosting. It also allows for deploying App parts and lists.
Provider hosted Apps
The provider hosted App on the other hand requires a provider to host the App, for example Azure or an On-Premises web server. It allows for server side code, and can be written in any language, so even in PHP or Ruby. This type of App has the big advantage of tapping into a broad spectrum of web technologies and languages. C# is great, but not for everyone. Just like with SharePoint hosted Apps, a provider hosted App can deploy App parts or lists to SharePoint. A provider hosted App offers much more flexibility, but requires more responsibility for the hosting environment and custom server side code.
Bonus: The console application
It is also important to mention that not everything which used to be a SharePoint farm solution has to become an app. With the client side object model, many tasks, especially the ones which only have to be done once (= feature activation in farm solution) or on a schedule (= TimerJobs in farm solutions) can now also be solved through console applications using the client side object model (CSOM).
App model limitations
There are of course also many disadvantages of the App model compared to full trust code, mainly because of the restricted API and the sandboxed deployment of your code.
Many common customization scenarios that were very easy to solve in farm solutions are now more complicated or even impossible to be done in the same way with the app model due to being unable to use the feature framework, deploy farm (Office365 tenant) wide solutions, no access to the underlying systems eg. to use HttpHandlers and HttpModules and many more.
On top of that, the guidance what to customize and what not is changing at a fast pace. For example using custom masterpages, which was long considered as the best option to apply custom branding, is now the new evil and discouraged. Heather Solomon just recently wrote about the implications of this change in her excellent blog “To brand or not to brand, that is the SharePoint Online Question“.
This means that when you are transforming your solutions to the SharePoint App model, you often have to rethink the existing solutions entirely and usually need to re-implement them from scratch in order to make them future proof. Microsoft is aware of this challenge and works together with the SharePoint community on the OfficeDev Patterns & Practices to provide a standardized core library for many scenarios and with plenty of sample implementations for the common challenges with the App model.
Where to host your App?
Again upfront you need to think about where are specific functionally of your application will be hosted. A SharePoint hosted App does not require additional hosting and can be hosted on either your on-premises farm, or in Office 365.
It’s a different story for a provider hosted App. A dedicated server, either in the cloud like Azure, or on-pemises is required to host the App. Hosting in Azure is the preferred option of Microsoft obviously, but with a good reason: Authentication between Azure and Office 365 is easily configured. Otherwise additional manual steps are required to configure authentication between the provider host and SharePoint.
Because many customizations often only have to be done once per site/tenant/webapplication they can be implemented as console applications and run on a local administrator machine or as a scheduled windows task on a job server (on-premises or in the cloud). For reoccurring tasks a great option is to use an Azure Webjob, which Tobias Zimmergren described in detail in his great blog “Getting Started with building Azure WebJobs (“Timer Jobs”) for your Office 365 sites“.
A change for the long term
The road Microsoft has travelled is a bit confusing, and they hit a few bumps along the way. From full trust farm solutions, to sandboxed solutions, to finally the new SharePoint App model. It looks like the App model finally has arrived and that this new way of doing things is here to stay.
Cloud Applications benefit greatly, but also on-premises solutions. Development is no longer tightly coupled with the SharePoint core, and different technologies and programming languages can be used as developers see fit. Although it is a very different way of doing things for many SharePoint people, the benefits are massive.
Hence, even if your organization is still using on-premises SharePoint and has no intention right now to migrate to the cloud or to build up a hybrid environment, the advantages in regards of maintenance upgradeability and future proofness of the SharePoint App model outweigh the flexibility of the farm solutions by far and will likely save you from costly migrations in the future throughout the App lifecycle.
In the next post in this series I will look in depth at ‘Assessment and Planning’ – how to analyze existing solutions using a number of techniques and tools.
