Update: You can now download the Office 365 SharePoint Version Checker Add-in from the Microsoft Store. Get it here.
--------
As I mentioned in my inaugural blog post, when defining the architecture for a SharePoint application that runs on an Office 365 SharePoint site, you should take into account the fact that Office 365 tenancies are continually upgraded as the product evolves.
The Office 365 service upgrades might include API, HTML, CSS, or other changes that could break an application deployed to a prior version of a given tenancy. This is no different than how a Windows application could break after you install a Windows Service Pack, except you aren’t the one installing the Service Pack.
As a SharePoint developer or architect, you should think about how to prevent these changes from impacting your custom applications and how to ensure you are notified when your tenancy is upgraded. That way you can test your applications to ensure they work properly with the newer version of your tenancy.
A Pragmatic Approach to SharePoint Development
Like I mentioned before, I take a pragmatic approach to SharePoint development and I’m not here to rant about things; rather, I’m here to help you apply some pragmatic approaches to your development efforts as well.
That being said, because Office 365 tenancies are continually upgraded, wouldn’t it be nice to know the minute it happened so you could test your applications as quickly as possible to determine if they are working properly after a version upgrade?
Having such a capability at your fingertips would allow you to notify your users that your tenancy was upgraded, that applications are undergoing testing, and, in the event an application broke due to an upgrade, it could reduce your Help desk calls and the fire drills that go along with such scenarios.
What does all that add up to? It adds up to fewer Help desk calls (money saved), less stress (less gray hair), and a mature approach to working within an ever evolving cloud-based environment. I like the sound of that.
You might be wondering how you could implement such a capability. Here’s one way to go about it.
SharePoint-Hosted App to Check Office 365 Versions
I’ve cooked up a little SharePoint-hosted application that checks the version of an Office 365 tenancy every time it runs and stores the version in a SharePoint list that’s part of the App Web.
If the App finds a new version, it logs the version to the list and provides you a message that indicates your tenancy version has changed since the last time you ran the app. If the version hasn't changed, the app doesn’t do anything except tell you the version hasn't changed.
Now you’re probably thinking, “Well, that’s nice Todd, but how do I make sure the app runs frequently enough to let me know a version has changed?” That’s pretty easy--just set up a scheduled task to access the SharePoint App in a web browser on a regular basis.
At this point you’re probably wondering how you are notified when the version changes.
That’s the easiest part. Just sign up for an alert on the list that tracks the versions, and you will receive an email the minute a new version is logged to the list.
Here’s a simple flowchart which illustrates the process:
Here’s what the SharePoint App, which I named the O365 SP Version Checker, looks like at runtime.
As you can see, I have outputted a lot of information in the App to help you understand what it’s doing. I’ll walk you through it now.
Walking Through the O365 SP Version Checker App
It turns out there are three different version numbers associated with an Office 365 SharePoint tenancy. Well, at least I’ve found three of them.
These versions are the Extender Version, the Build version, and the SPProductNumber version. More about these in a bit.
If you know another way to check the tenancy version let me know and I’ll add it to the App.
First, the App determines the App Web Url, and it appends the _vti_pvt/service.cnf and _vti_pvt/buildversion.cnf suffixes to check for the Extender and Build versions, respectively.
In the screenshot, I have hidden my tenancy URL. The SPProductNumber version is obtained from the QueryString.
Next, the App makes calls to the two URLs to obtain their payloads which include the Extender and Build versions and it displays the raw payloads. Then the App parses the payloads to determine the version numbers.
After the version numbers are known, the App queries the Versions list to see if the versions have already been logged. If they have not been logged, it logs them to the list and displays a message a new version was found and logged.
Finally, the App displays a link to the Versions list so you can easily access it and peruse the version history for your O365 tenancy. Here’s what the list looks like.
As you can see, there are six entries in the Versions list. The first three entries, the ones that were created 6 minutes ago, were entries I manually added to the list for testing purposes.
The first three entries contain version numbers that correlate to an on-premises version of SharePoint I used to build the App.
I also chose to add these particular version numbers to point out something interesting: The version numbers for the SPProductNumber and Build number are identical on my on-premises development server; however, they differ on my Office 365 tenancy where this screenshot was taken.
Notice in the screenshot below, when I return to the page in the App which checks and logs the versions, it reports no new versions have been found.
I’m working on publishing this app to the SharePoint Marketplace, and it should be available soon. In my next post, I’ll dig into the code to show you how it works under the hood.
