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 :).

A

Hi fellas,

I’m currently getting my agenda ready for //build and I can hardly wait the keynotes. After going through the agenda, I found some very interesting sessions:

  • Diagnosing Issues with Windows Phone JavaScript Apps Using Visual Studio
  • Multitasking and Triggered Background Tasks for Windows Phone Apps (in regard to Windows Phone 8.1)
  • Building a Converged Phone and PC App using HTML and JavaScript

I guess we’ll be hearing about a share WinRT or something, between both desktop and mobile devices. From a developer’s perspective, that would rock!

A

There’s a lot to say in very short time:

  1. Attended Build 2012 in Redmond! Awesome!!! I really have to tell you more about how well MS organizes such events!
  2. Passed the Professional Scrum Master I assesment! Here comes # 2!
  3. Passes 70-483 exam from Microsoft. And if you’re wondering, the answer is no. They didn’t publish the preparation materials yet, nor the self-paced training kits nor anything! And for the sake of writing some more stuff here, of course I didn’t study for a minute for this exam, since I took it while attending Build 2012 :)
  4. Last but definittely not least, I got married too!

As for Build 2012, I had the chance to talk to Mark Russinovich, the guy responsible for Sysinternals and one of the guys on the Azure team (for two years already), who had an extraordinary talk on the internal stuff regarding Windows Azure, with Scott Guthrie, the Microsoft corporate VP for the Developer Division who had some great talks on Windows Azure and with lots and lots of developers on the Microsoft campus about Windows 8 (regarding Store apps, ReFS, power management etc.), Azure Storage, SQL Databases on Windows Azure, VS 2012 and also to some MS Parterners.

I absolutely loved the conference and I’m definittely willing to tell you more about it, if you want! Just contact me and we’ll gradly chat about it!

BR,

Alex

WP_20121101_014[1]