In this article I am going to describe how to separate your insights data gathered using Visual Studio Online Application Insights for different cloud services, such as staging versus production cloud services or totally different cloud services.

Current Challenge

 In the most common scenario, you'd want to test your cloud services in an Azure environment before making them publicly available. Moreover, you'd also want to test your application with a different dataset which contains a larger dataset. One way to do this is by creating a clone copy of your cloud service project directly inside your Visual Studio solution and changing each role's settings corresponding to your sandbox environment. Thus you'll have a fidel copy of your bits running in the cloud and using a mock dataset.

However, the idea of an insights tool is to provide you more than technical data regarding application performance and accidental crashes. What you'd normally want from an insights tool is also usage data on how your application is being used, what features are mostly accessed, how features perform and how your different types of customers are using your applications.

In the current version of Application Insights, you are faced with the following challenge: given the fact that you have to configure your Application Insights either in code, by providing values to the constructors the tool is calling, or by using a configuration file called ApplicationInsights. Config, how can you separate the insights data gathered on your staging environment from the data gathered on your production environment?


The first thing you'll have to do is create a new Application Insights application in the Application Insights portal. Remember to choose a corresponding name for this so that you'll always remember that the data gathered here represents your staging environment.

By doing this you'll end up with two different Application Insights applications in your portal that you'll finally be linking to a single code-base. The obvious question that arises is how do you configure an additional Application Insights application to the same code? The coolest thing would be to create something similar to an ApplicationInsights.Staging.config file, yet such an option is not available with the current release of Application Insights.

One way to achieve this is by configuring your staging environment of your cloud service (or your different cloud service) roles' settings with different Application Insights component keys (ComponentID and ComponentName) in your .cscfg file. However, should your settings go deeper based on the environment, you'll end up with many settings that will eventually be difficult to manage: you could, for example, change the threshold execution time for your production environment for a lower value, or change the sensitivity threshold for your staging environment so that MMA reports performance events that take less than the production's threshold and so on.

A way more manageable way to create a different configuration set for Application Insights is by creating a copy of your ApplicationInsights.config file for each of your environments. Considering that for the staging environment I would also be eventually debugging the code, I went by creating an ApplicationInsights.Debug.config file corresponding for this environment, and an ApplicationInsights.Release.config file for the production environment. Each file has it's corresponding component ID and component name, as they were defined by the Application Insights portal.

The idea behind this solution is to automate the selection and copy of the correct configuration file for Application Insights by using a Visual Studio build event.

In order to link these files to the environment correctly, copy them to a folder (for better project maintainability) called 'AppInsightsConfigs' and create a project build event that will run after the project was built:


"$(ProjectDir)AppInsightsConfigs\ApplicationInsights.$(ConfigurationName).config" "$(TargetDir)ApplicationInsights.config"

What this command does is copy either the ApplicationInsights.Debug.config or ApplicationInsights.Release.config file from the AppInsightsConfigs folder that resides in the project folder, to the target folder with the name ApplicationInsights.config. In the previous command line, $(ProjectDir), $(ConfigurationName) and $(TargetDir) are macros defined by Visual Studio that return the project folder, configuration name (Debug or Release) and target folder respectively (usually \bin).

Final Note

One thing you do have to care of is the fact that if you keep your ApplicationInsights.config file in the main project folder (as the Application Insights Visual Studio extension will probably do), your build event won't actually copy your correct file, meaning that you'll get the ApplicationInsights.config file from your project folder instead. In order to overcome this impediment, you can either rename or completely delete the original file. This will, however, also deactivate your project context menu option that allows you to quickly open the Application Insights application dashboard and will activate the 'Add Application Insights...' menu option again. Make sure you don't select this option, or you'll have to delete the ApplicationInsights.config file from your project folder again.