Decorating errors with version number using Azure Websites

Did you know that elmah.io 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:

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

A simple key value pair telling the system that the current software is part of the 1.7.0.3 release. To decorate every message logged to elmah.io 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 elmah.io.client, we get a chance to intercept and change all messages being send off to the elmah.io 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)" />

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 https://yoursite.scm.azurewebsites.net). 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.



Features steps
We monitor your websites

We monitor your websites

We monitor your websites for crashes and availability. This helps you get an overview of the quality of your applications and to spot trends in your releases.

We notify you

We notify you

We notify you when errors starts happening using Slack, HipChat, mail or other forms of communication to help you react to errors before your users do.

We help you fix bugs

We help you fix bugs

We help you fix bugs quickly by combining error diagnostic information with innovative quick fixes and answers from Stack Overflow and social media.

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