Auto-update your Azure Site Extension

With Azure Site Extensions, you are able to extend any Azure Web App pretty easily and enhance the site’s functionality. For example, there are extensions which integrate New Relic and Visual Studio Online to any Azure Web App.  You can even write your own and post them to the Site Extension gallery.  If you don’t know how to create a site extension and publish it to the gallery, you can find the instructions here.

However, updating those site extensions can be a bit of a hassle. Previously, when publishing a new version of your site extension, you needed the users to browse the Site Extension Gallery to obtain the newest version and then manually deploy the update via the update button. Now, we’re introducing a way for you to let your site extensions auto-update themselves with just one line of code!

Enable auto-updates

One Liner

To make your site extension auto-update you just need to include the following script tag in your site extension’s home page (or any page your users will often visit):

Simple as that.

Now every time anyone navigates to your site extension, the script will be running in the background and will check to see if there’s a newer version of the extension available. If there is, the script will update the user’s copy of your site extension and ask them to refresh their page to get the new bits. All in just a few seconds!

Note: The auto-update feature works for site extensions with a UI.

Install via Bower

If you prefer using Bower, we’ve got you covered there as well. You can install the script via bower by running:

bower install  azure-site-extension-updater

Using a custom applicationHost.xdt file

If you don’t use an applicationHost.xdt file for your site extension, you can skip this section.  If you do, there’s something you need to be aware of.

One thing the auto-updater needs from you is that the id you publish in your site extension’s *.nuspec file should match the route you list for your site extension in your applicationHost.xdt file.

Note: If you don’t include an applicationHost.xdt file with your site extension, Kudu will generate a default one for you with the correct route

Example *.nuspec file:

MySiteExtension7.0.0ZainRizviZainRizvihttp://www.github.com/zainrizvi/mysite/licensehttp://www.github.com/zainrizvi/mysitehttp://www.github.com/zainrizvi/mysite/image.icofalsePackage descriptionSummary of changes made in this release of the package.Copyright 2015Tag1 Tag2

Example applicationHost.xdt file:

Limitations

The auto-update script comes with two caveats:

1. Because the auto-update script is a javascript file that has to run in a browser, for your site extension to actually get updated your user has to navigate to the page that imports the script. This means only UI-based site extensions can be auto-updated.
2. The update occurs by making api calls to the Kudu (scm) site, but in order to get access to the Kudu site the user has to be authenticated. This means that if the route to your site extension isn’t based off of the Kudu site already (if your site extension isn’t routed under https://.scm.azurewebsites.net/…) then the site extension will lack the necessary authorization and won’t get auto-updated. (By default your site extension is routed under the Kudu site)

How does it work?

The script parses the url of the page to figure out the name of the site extension. So if your site extension is located at:

 https://.scm.azurewebsites.net/MySiteExtension/

It’ll figure that the name must be “MySiteExtension”.

With the name in hand, the script just makes a couple API calls to the Kudu site to see if there is any updated version of your site extension available. If updates are available, then the script prompts Kudu to install the latest version of the site extension by sending:

PUT https://.scm.azurewebsites.net/api/siteExtensions/

This is the same request made when you click the “update” button on a site extension in the gallery.

Happy coding!

To learn more, you can find the GitHub project and the unminified source here.