Decorating errors with version number using Azure Websites

Did you know that supports custom version numbering on all of your errors? If not, take a look at Adding Version Information. Having a version number on all errors, is extremely useful for tracking bad releases. In this post, I'll explain different approaches for automatically decorating your errors with the version number of your software.

To make it easy to change and read, we'll add the version number in a new app setting named Version. This could might as well have been a version.txt file in App_Data, an updated AssemblyInfo.cs file before build or whatever approach you use to stamp your releases with versions.

The version settings in our example looks like this:

  <add key="Version" value="" />

A simple key value pair telling the system that the current software is part of the release. To decorate every message logged to with this version, add the following lines during your initialization code (like Global.asax.cs, Startup.cs or similar):

Elmah.ErrorLog.GetDefault(null); // Forces creation of logger client
var logger = ErrorLog.Client;
if (logger != null)
    logger.OnMessage += (sender, args) =>
        if (args.Message == null) return;
        args.Message.Version = ConfigurationManager.AppSettings["Version"];

Using the OnMessage event on the, we get a chance to intercept and change all messages being send off to the API. In the code above, the Version property is set to the value of the app settings specified in web.config. In fact this approach is not specific to Azure at all and is considered the preferred way of decorating messages with a version number.

As for Azure, pretty much the same rules apply, since Azure websites are simply plain old ASP.NET (MVC/Web API) apps. Whether or not you use VSTS, TeamCity, Octopus or similar to build the version number, setting that app setting is straight forward. But what about git deployments using the Kudu engine? With this approach, every push to a git repository of your choice, is automatically build end deployed to Azure. Using this popular approach, you are pretty much stuck with setting version numbers manually and checking it into Git. Unfortunately, Kudo doesn't provide any information about the current deployment through environment variables or similar.

Using the Post Deployment Action Hooks in Kudo, we are able to hook custom code into the deployment process, setting the version number. Deployment hooks are basically scripts/executables that runs after the deployment has completed successfully. To set a version number after a deployment, we can do a bit of web.config transformation magic and combining it with PowerShell. First, update your Web.Release.Config:

<add key="Version" value="$version" xdt:Transform="SetAttributes" xdt:Locator="Match(key)" />

For more information about Web.config transformations, check out the blog post Web.config transformations - The definitive syntax guide. For help debugging problems, we have created the Web.config Transformation Tester.

When running a release build, the Version setting is updated with the value of $version. Then create a new PowerShell script:

$version = Get-Date -format u
(Get-Content ..\wwwroot\web.config).replace('$version', $version) | Set-Content ..\wwwroot\web.config

The script calculates a version number from the current date and time and update the $version string inside the config file.

Finally, you need to upload your PowerShell file. The easiest approach is to navigate to your Kudo UI (located on Go to the Debug console and navigate to site\deployments\tools\PostDeploymentActions (create it if it doesn't exist).

To create the new PowerShell file, write the following in the prompt:

touch update-version-number.ps1

Edit the new file and paste the PowerShell from the previous step. That's it! Your update-version-number.ps1 script now runs as part of every deploy, updating the version app setting with the current date and time. Error logging and Uptime Monitoring for your web apps

This blog post is brought to you by is error logging, uptime monitoring, deployment tracking, and service heartbeats for your .NET and JavaScript applications. Stop relying on your users to notify you when something is wrong or dig through hundreds of megabytes of log files spread across servers. With, we store all of your log messages, notify you through popular channels like email, Slack, and Microsoft Teams, and help you fix errors fast.

See how we can help you monitor your website for crashes Monitor your website