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)" />
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 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.