It will set application version for telemetry items so you can group telemetry by version and understand in which version of application certain exception happened.
Note: Yes, it is confusing name. SDK refers to application as “Component” when in UI it is called “Application”.
This code snippet uses constant string as an application version. My guess is that this version represent semantic version of API call. If you versioned your REST API using urls like this:
https://management.azure.com/subscriptions?api-version=2014-04-01-preview you’d probably need to change your middleware to read version from
api-version query string parameter.
Semantic version is good for certain telemetry reports. For instance you can see how much traffic goes to which version of API to decide when to shut down older version. However semantic version is something you need to code explicitly - there is no generic way to version applications and APIs.
So instead of using semantic version - we suggest to use automatically generated version number. For instance, this article suggest to use Assembly version of your application as application version.
You’ll need to use wildcard in
and use telemetry initializer to initialize application version:
Now all telemetry items will be marked with the version like
32696 are some semi-random numbers.
Drawback of this approach is that again, you need to write some code. Furthermore, there is no way to detect which assembly is a “main” assembly of an application. So your telemetry initializer should be application specific.
This brings us to the reason I write this blog post. Visual Studio has a feature that I believe undeservedly is not well known and widely used. It is called build information file or
Turing this feature on is simple. Just add a property to your project file:
1 2 3
This will generate the file
bin/$(ProjectName).BuildInfo.config when you compile locally with the commit number and auto-generated build label and
BuildInfo.config when you publish your application. For instance, once I enabled continues integration in Visual Studio online this file is placed next to
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27
It is great to have this file published with your application as you will always know which version of source code it was built from.
Application Insights Web SDK will install context initializer called
BuildInfoConfigComponentVersionContextInitializer that will read this file and mark telemetry items with the application version equal to
BuildLabel from the file above. In this example it will be
TestBuildInfoApp_CD_20150618.1. Now, looking at your telemetry you can always find the build that produced this binary.
Here are some additional details on how this feature used to work in the old version of Application Insights. From this article you can find that you can use
IncludeServerNameInBuildInfo property to enrich
BuildInfo.config even more and how to configure copying of this file next to
web.config while developing. Do not forget to
.gitignore it though…