First of all, if you’re new to Application Insights, check out this link and this link too. In a word, Application Insights offers you deep insight data on your application performance and usage. And it rocks while doing that, too!
Application Insights is since last week no longer under preview. However, if you’re trying out Application Insights right now, you have obviously already found out that the corresponding NuGet package is still in beta (version 0.7.x.x) and, should you have tried out Application Insights for a longer time now, you’ve probably realized that there are a lot of changes in the configuration schema too.
One of the things I don’t like about the new schema is the lack of a special component ID (which basically defines a specific Application Insights entry = application) for debugging. This also means that when you debug, you’ll get your debug data mixed with the production data, which is bad.
However, even if the guys at Application Insights (which I’ve just met at Build 2014) have removed this one particular feature (which, I admit, didn’t work out for me as I expected), they’ve added tons of new features which are worth checking out.
Now, to the post subject. How do you collect usage and performance data if you have different cloud projects (for different environments, such as a staging and a production environment) and a single code-base (meaning, a single project containing your code). The question might be tricky, since you’ll have to add the .config file directly inside your project that contains your code (for example, the web project), rather than the cloud project.
For such a scenario, here’s what I did. I created a new folder inside the project folder (e.g. ‘AppInsightsConfigs’) which contains my applicationinsights.config files that correspond for each environment. This basically gives me the option to define a config file for the staging deplyoment (ApplicationInsights.Debug.config) and another file for the production deployment (Applicationinsights.Release.config). Obviously, each .config file has its own ComponentId and ComponentName settings.
What I do next is to create either a pre-build or post-build command that contains this simple command line:
copy “$(ProjectDir)AppInsightsConfigsApplicationInsights.$(ConfigurationName).config” “$(TargetDir)ApplicationInsights.config”
This command simply writes either the .Debug.config or .Release.config over your output directory, which works fine for me since I want to have the Debug version in a staging enviroment (for remote-debugging scenarios especially) and a Release version in the production environment (who would add the debugging symbols and loose the code optimization feature inside production?!).
One thing worth mentioning out is that if you rung this as a pre-build or post-build command, you will not get the right version of the .config file unless you exclude or change the name of the ApplicationInsights.config file the Visual Studio Application Insights extension automatically adds (or the one you’ve added manually). Moreover, if you decide to run the command as a pre-build command, you also have the option of replacing the $(TargetDir) macro with the $(ProjectDir) macro, which will copy the desired configuration file over your original ApplicationInsights.config from the root directory, so that no exclude or rename is necessary. However, in this case please keep in mind that any change you do inside your ApplicationInsights.config file will be lost the moment you run a build command. I also don’t recommend you to run the command as a post-build command with the $(ProjectDir) macro as the destination folder, because you’ll need to build you project twice for the command to work and I’m sure you’ll almost certainly forget to do so :).