Skip to main content


The (updated) SharePoint app model development approach

I was recently invited to attend a session at the Microsoft campus in Redmond titled “Transitioning SharePoint Full Trust Code to Application Model Solutions Airlift”.  So, aside from the long title, what exactly was this session going to provide?  I did get a chance to see the preliminary agenda so I did have some idea what the main topics were, but I still wasn’t exactly clear on what I was going to get out of this.  Nevertheless, I was intrigued and knew from the agenda that there were some great topics being discussed so I made my travel arrangements and headed to Redmond.  Little did I know at that time that I was about to attend a session that really put things into perspective with the current state of SharePoint and change how I think about approaching both on-prem and SharePoint Online projects going forward.  In this post, I will go over the key topics that I took away from these sessions and the recommended guidance to address these topics.
airlift intro
At a high level, the primary goal was to bring partners and clients up to speed on converting SharePoint Full Trust Code (FTC) to app model.  Topics ranged from initial deployment, to maintenance, upgrades, migrations, etc., the whole gambit, essentially.  I have been following the Office 365 Developer Patterns and Practices Team (PnP) for some time so I did have some idea of this before the event, but after sitting through the sessions, going through the labs, and talking with others at the event, it really put things into perspective and made me realize the paradigm shift the platform started with SharePoint 2013 and how important it is to get on board now, even if you’re an on-prem customer.

App model != apps/app parts/app webs

When SharePoint 2013 was making its debut, SharePoint apps were all the rage… many a session was attended discussing SharePoint apps, app webs, host webs, etc.  What seems to have gotten lost in a lot of that shuffle was the focus on the app model and not just SharePoint apps.  It seems that Microsoft is aware of this and the PnP team is trying to help guide everyone to focus on app model (client side code) and not just SharePoint apps.  While apps have their place, they are not the star in my mind and too much focus has been around apps in general since SharePoint 2013 was released.  Focusing on the app model in general (not just apps!) is key and, for those more involve with ECM and Intranet style projects, it’s necessary since apps don’t always have the best fit with those types of projects.

Avoid Custom Master Pages

Let’s be honest, this one can be a little hard to swallow… even though it does make sense, most of us will continue to create custom mater pages for heavily branded sites.  After all, many SharePoint projects start off with a focus on making it not look like SharePoint.  This doesn’t necessarily mean that a custom master page is needed right; however, the conversations and design sessions tend go down this path.  The PnP guidance is not to say that its wrong but to avoid custom master pages unless the requirements dictate otherwise. Consider what happens if you do create a custom master page: you create a custom master page, Microsoft releases a new master page with new functionality but your custom master page will not include these changes.  This means that you’d need to go through the effort to either include the new changes in your custom master page or create another custom master page based on the newly released master page.  The slides explain this more clearly than I do here and it’s probably more of an issue for SharePoint Online customers than on-prem customers.  However, it still applies because an on-prem upgrade to the next version of SharePoint usually includes some activities around custom master pages.  This could have all been avoided if no custom master page was created to begin with, but sometimes it’s necessary, we come to terms with it, create our custom master pages, move on, and deal with the issue during the next upgrade.

Remote Provisioning Instead of Feature Stapling and Server Side Code

sp2013 dev imageTraditionally, feature stapling is used to help with the site provisioning process.  This gets us far enough to have some features automatically activated on a site after it has been created (ie: apply branding) but it doesn’t really help address things like collecting information from the end user for classifying the site for search purposes, etc.  A far more extensible pattern to use is to create a provider hosted app that prompts the user for the expected information and provisions the sites via CSOM, REST, etc.  Not only does this pattern give you more flexibility, but it completely avoids farm solutions, custom site definitions, web templates, etc.  This is a win-win all around, with one exception… you have to build it… not only do you have to build it, but you have to ensure the existing SharePoint UI has the proper hooks to take the users to the provider hosted app instead of bypassing it and using the traditional site creation process within SharePoint.

Create an ‘assets’ site for common files instead of using the Layouts folder

The goal here is to have a common site collection that can be references as needed by other sites for css, js, images, etc.  This is a necessity in SharePoint Online, since Farm solutions are not supported, but should also be considered for on-prem environments as well.  This guidance provides a few benefits:

  1. no farm solution is needed and therefore no downtime to deploy the files (ie: app pools are not recycled and server admin’s don’t need to deploy a WSP)
  2. files can be easily updated via SharePoint designer for quick fixes without requiring a special deployment.

While this sounds great, there are some limitations.  Specifically, JSLink, CSSLink, and ScriptLink controls are site collection scoped and may not support loading files outside the current site collection.  For example, with JSLink, the path must start with a supported token such as ~site or ~sitecollection; otherwise, the file is not loaded.

The Recommended Approach to Classic Timer Jobs

To create something similar to timer jobs with the new app model approach, you would need to create a process external to SharePoint that communicates with it via CSOM and REST API’s.  The biggest downside here is that it is not going to be as fast as running on the farm itself.  This can be done in many ways… scheduled tasks, PowerShell scripts, console applications, Azure web jobs, you name it as long as it can use CSOM and REST.

SharePoint Code Analysis Framework (SPCAF)

spcafAs a professional that has worked with SharePoint for so many years I am really looking forward to digging into this tool more.  Have you ever worked on a SharePoint development project and wanted to really know where you stand with the final product in terms of best practices, maintainability, stability, security, etc.?  Did you ever want a tool that can analyze not only the managed .NET code for undisposed objects, but also look through your client side Javascript files for other issues/concerns?  SPCAF appears to do all of that and I’m eagerly looking forward to using it for some upcoming projects.  I am mentioning this here because this tool looks tremendously useful not only for reviewing code and solutions before deploying to production, but also to help prepare for migration and upgrade processes.  I have a task for myself to follow up with this and recommend everyone else in this profession to at least take a look and try out the trial.

Stop using SharePoint Solutions (both farm and sandbox solutions)

By now, this message is pretty clear… we’ve seen it coming with all the new API’s in SharePoint 2013, the deprecation of server side code in sandbox solutions, and lack of support for farm solutions in SharePoint Online.  In fact, the PnP guidance is to avoid feature based development altogether.  Feature based development is not necessarily going away… after-all, the underlying platform is based on it.  However, it does not provide the best long term vision for the solution when you take into consideration what complications this approach will cause for future code updates, platform upgrades, and migrations to SharePoint Online.  There are, of course, those situations where farm solutions are necessary, such as server side code, feature stapling, etc., but for most other situations, farm and sandbox generally solutions are not necessary.  Shifting away from farm and sandbox solutions and focusing on deployment and configuration activities via client side code provides a lot more flexibility than using solutions but this shift also implies you’re willing to invest the time to write the scripts, debug them, etc. rather than take advantage of the somewhat simple solution deployment process that we’ve been using for so many years now.
This is a very interesting topic and arguably the most important one for me in these sessions… we’ve been developing for SharePoint for many years now using features and solutions.  So, what gives… why are we suddenly not supposed to do this anymore?  I’m going to leave the rest of this topic for another future blog post… for now, I will say that I generally agree with this guidance and I strongly recommend you check out the PowerPoint decks provided by the PnP team and follow their wiki, yammer group, etc.

Closing Comments

Ultimately, this is all just guidance… none of this is set in stone.  In fact, it is very new and has been evolving for some time.  Its easy to make recommendations and say why it’s best to follow this guidance, but it’s another thing altogether to follow it and implement it in your projects.   There will be people that agree with this guidance and people who disagree… after-all, it does have its flaws.  For example, are we supposed to stop using the Visual Studio tooling for SharePoint unless we’re building apps?  Generally speaking, yes, this guidance implies that… but what about all the official Microsoft documentation, Technet articles, etc.?  Are they wrong?  No, not necessarily… but they do impose limitations on the solution right out of the gate that would be best to avoid if possible.  What about the design manager in SharePoint 2013?  Should we stop using that because it uses sandbox solutions to import/export?  Again, not necessarily… it has its benefits and its pretty easy to use… but it also has its downsides and limitations that can be addressed via CSOM.
My recommendation is to consider all of these points when developing for SharePoint to see what makes the most sense for your situation.  Even if this is not new information for you, I recommend you checkout the decks provided by the PnP team to see if there is anything new you can get out of it.  The development path chosen should satisfy not only the short term goals but also keep in mind what could happen in the future… eliminating farm solution dependencies is generally a good place to start and moving to CSOM for deployment & configuration should become easier in time as more provisioning scripts and examples are made available.
Here at Perficient, we have projects that are following this guidance very closely, and other projects that do not for various reasons.  Some of our architects and developers have invested time to build up some very comprehensive CSOM libraries to address deployment and configuration activities and it will be interesting to see what the PnP team releases in the near future as well.  I can personally speak to following this guidance as I’ve been working with SharePoint since SharePoint 2003 and even though following this guidance can sometimes be a little challenging, once you’re past those challenges the benefits are huge ranging from fully automated deployments, to troubleshooting deployments (ever try to troubleshoot weird errors from deploying WSP’s or activating features?  It’s not always quick and easy), to delivering solutions that are compatible with on-prem environments and SharePoint Online right out of the gate.

Links of reference:

Thoughts on “The (updated) SharePoint app model development approach”

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Michael Toole, Director - Microsoft Azure

Michael Toole is a long-time professional services consultant who specializes in Microsoft Solutions on Azure.  As Perficent’s Azure Practice Director, he focuses on supporting clients looking to migrate or modernize applications on Azure and innovating with new cloud-based features, including infusing those applications with new security & AI capabilities.

More from this Author

Follow Us