Tagged: SharePoint Add-in Model

Speaking at SharePoint Fest DC 2017!

This April, I will be joining SharePoint experts from around the world at SharePoint Fest DC 2017! I am very excited to be debuting a new session this year:

DEV 200 – Updating Legacy SharePoint Customizations to the Add-in Model

Many organizations using SharePoint maintain large portfolios of custom code solutions that leverage different legacy development approaches advocated by Microsoft through the years, and most of the custom code developed for earlier versions of SharePoint cannot be directly migrated to the cloud. In this session, you will learn how the SharePoint Add-in model allows you to develop maintainable customizations that have traditionally been accomplished using custom server-side code. You will learn how to categorize the types of user interface, declarative, and timer job customizations you may have performed with farm and sandboxed solutions in the past and understand how to approach developing each of them using techniques from the Add-in model.

If you register now and use code JesseeDC200 at checkout, you can save $200 off the purchase of a Gold, Platinum, or Diamond pass!

This will be my third SharePoint Fest event and my second SharePoint Fest DC. I absolutely love this conference and the DC location is as convenient as it gets for mass transit…just step off the train and you are there! I look forward to seeing you there.

What’s in a name? The challenges posed by renaming SharePoint “apps” to “Add-ins”

As you probably know by now, the following message started appearing on all MSDN pages related to apps for SharePoint in early May (the wording has recently been tweaked; the latest version of the message is shown below):

apps1The Note above links to New name for apps for Office and SharePoint.

My initial reaction to this news was something to the effect of, “OK, that’s interesting but no biggie. I’ll just make a mental note to say Add-in now instead of app (oh, and do a global search and replace in all my slide decks)…”

The more I thought about it, though, this simple name change was going to pose many challenges for customers and consultants alike. I have been speaking about “apps for SharePoint” for almost three years now and one of the most trivial, yet biggest stumbling blocks seemed to be:

“So when I want to add a custom list to my site, I go to ‘Add an app’ now?”
“Well, yes, but doesn’t that at least make more sense than going to ‘More Options…’?”
“I guess. But do I need to configure the app domain and do all that other stuff you talked about just to add a list now?”
“No, you only need to do that if you will be connecting to the Office Store or if your developers will be leveraging the app model.”

It’s already been more than a little awkward as I feel the need to interject whenever someone says something about “apps for SharePoint” or the “SharePoint app model.”

Along with a few other developers and consultants, I shared my concerns about the name change in semi-public discussions on Facebook and Yammer. As a result, Jeremy Thake was kind enough to publish a blog post containing the Office 365 ‘App Model’ rename cheat sheet. This post is fantastic and gives some more background about why the name change was necessary. Jeremy has certainly taken a beating from some of the folks out there who are frustrated, confused, and/or bewildered by the name change, and I applaud his efforts in listening to our concerns and providing this level of information to us.

Having spent the better part of the last three years educating our customers and development teams about the “app model,” we must now update our vocabulary to ensure we are speaking with accuracy and precision about the many facets of custom development for SharePoint and Office 365. The “cheat sheet” is a good start, but it omits at least a few relevant “app-isms” that I have listed below by what I assume will be their new names:

    • Add-in prefix
    • Add-in domain
    • Add-in catalog
    • The file extension of the generated Add-in package (currently *.app)
    • Add-in manifest (AppManifest.xml)
    • Add-in principal
    • Add-in-only calls to SharePoint
    • Add-in authorization policy types (Add-in + User, Add-in-only)
    • Add-in Management Service Application
    • Add-in registration and management pages (currently /_layouts/15/AppRegNew.aspx, AppInv.aspx, AppPrincipals.aspx)
    • Countless other Add-in-related PowerShell cmdlets and APIs (NOTE: word on the street is that the app-related names referenced in the APIs will not be changing)

After three years, there is obviously a great deal of sample code and documentation out there that references the “app model.” The Office 365 PnP repository is no exception:

People who are willing to invest the time and energy to ensure that documentation and tooling around SharePoint Add-ins is up-to-date with the proper naming should be lauded, as there will no doubt be a great deal of confusion among customers and developers as they figure out what terminology to use and which examples are relevant when searching for accurate, up-to-date information about building SharePoint Add-ins. It appears that folks who are fortunate enough to be under NDA with Microsoft also have a better sense of why this name change was necessary, so let’s hope that information makes its way out to the rest of the community soon so we can answer the inevitable questions from our customers about “Why?” or “What’s the difference between an app and an Add-in?” or “Now where do I go to add a custom list to my site?”

(Yes, you guessed it…to add a custom list to your site, you will soon have to go to “Add an Add-in.”)

What are your thoughts on this change? Let’s keep the discussion going. I will be updating this post as we experience the impact of these changes over time.