Recently, I have shown, how to enable Application Insights within own WCF server application (look here). It might similarly work in other kinds of apps, so we won’t bother with further demystification of this procedure. But as you might suspect (or already stepped on), you will quickly require more metadata transmitted than it is done by default.

My scenario is pretty simple. The WCF server is installed multiple times, in multiple physical locations across the whole country. And they all just sit there, working since most of the bugs aren’t so critical. It can’t be even updated everywhere at the same time. So how to actually distinguish between different instances and app versions in case of a crash or other serious misbehaviors?

And the answer is – ITelemetryInitializer.

This kind of objects are responsible for performing initialization of the telemetry data gathered and then sent back to the Azure’s AppInsights service.

Here is the recipe, how to define and enable one in own project:

1) First create a class that implements ITelemetryInitializer interface.

2) Within Initialize() method, set additional context properties. To match my scenario, let it be two fields:

  • ClientInstance” – to let know, which server it’s running on (yes, it should be read from external configuration file, but should be clear enough for now, as I hard-code it)
  • BuildInfo” – to inform about application version running there, which I read directly from the assembly name

Of course the way it was obtained should be updated to match the logic in your app.

public sealed class ClientInstanceTelemetryInitializer : ITelemetryInitializer
    private const string ClientInstanceParam = "ClientInstance";
    private const string BuildInfoParam = "BuildInfo";

    private readonly string _instance;
    private readonly string _version;

    public ClientInstanceTelemetryInitializer()
        _instance = "beaa9ac0-3267-41e4-9c14-2167271aca4d"; // should be different for each running instance
        _version = new AssemblyName(Assembly.GetExecutingAssembly().FullName).Version;

    /// <inheritdoc />
    void ITelemetryInitializer.Initialize(ITelemetry telemetry)
        telemetry.Context.Properties[ClientInstanceParam] = _instance;
        telemetry.Context.Properties[BuildInfoParam] = _version;

3) Finally, register the initializer via ApplicationInsights.config file (this file was added automatically to the project, when AppInsights NuGet packages were installed inside the previous guide). Simply add the type at the end of TelemetryInitializers section. It will be instantiated automatically at application startup.

Telemetry Initializers

And that was all again.


Now, when navigating to the crash logs on Azure, open a request details, click ‘Show all’ properties and the view should look similar to this one:

Azure Telemetry Info

“Custom Data” section contains info about ClientIntance and BuildInfo as expected.



Here I would like to present a small recipe, that will let you enable monitoring of WCF server-side calls with Microsoft’s ApplicationInsights service. It might help you in analytics of:

  • what services are used mosts
  • what hours users are active
  • what are the response times
  • what is called far too often and needs optimization
  • and probably most important thing - what crashed, why, when with the callstack!

It’s pretty straightforward and I split it into two parts.
First part - tasks are required to be done on the Azure side. For the foremost – you will need an Azure Account and an active subscription. I am assuming you already got one. Details are out of the subject for this tutorial. Even though Azure is a paid service, an ApplicationInsights till first million of actions is free as I remember correctly.
Second part – how to update the server-side of an application to utilize the Application Insights service. It focuses on proper packages installation via NuGet and the configuration.

Let’s go then. Do it on Azure:

  1. Login into Azure Portal.
  2. Click on “Create a resource” and input “Application Insights” in a search field. Then click “Create” button.

    Azure Create AppInsights resource

  3. Select an “ASP.NET web application” and complete the process.
  4. After few seconds, new service will be created, navigate to it.
  5. What is really required to store/remember is called “Instrumentation key”. Obtain it from the “Properties” section or via “Essentials” part of the “Overview” section as shown below.

    Azure AppInsights Overview

  6. We are done here.

Now, it’s time to update the ASP.NET WCF application, to post metrics and call to Azure appropriately.

  1. Open your solution in Visual Studio 2015 Community (or newer).
  2. Navigate to “Tools –> NuGet Package Manager –> Package Manager Settings –> Package Source” as on picture below.
  3. Add new source for AppInsights SDK (open-sourced and hosted on GitHub).

    NuGet Sources

    Name it anyhow you like, and use “https://www.myget.org/F/applicationinsights-sdk-labs/nuget” as source URL.

  4. Install the package: “Microsoft.ApplicationInsights.Wcf” (Include prerelease should be checked). It should also download all other packages it depends on.

    AppInsights Packages

  5. Now, inside the Globa.asax file, update the “Application_Start” method. Enable the monitoring of the application by placing the “Instrumentation Key”. The value we got earlied from Azure Portal, when the cloud service itself was created.

    TelemetryConfiguration.Active.InstrumentationKey = "my-instrumentation-key";

    AppInsights Instrumentation Key

  6. All the other necessary configutaion could be tweaked via code or ApplicationInsights.configfile, that was added to the project during packages installation. At this time, we don’t need to modify it anyhow.
  7. So we are done. Now the new version of the application is ready to be deployed. Once this is finished, statistics will be uploaded and visible through poral almost in real time.

    If you can visit the portal again after some time, instead of being empty, it should display content as follows:

    Azure AppInsights working

That was it!


After recent upgrade to Windows 10 Fall Creators Update my wake-on-lan feature of the desktop PC stopped to work. It was not very surprising, as most of the settings during such a big OS update usually goes to defaults.

Here are two simple steps to restore it. Only two - as I already had it enabled in my UEFI BIOS on the motherboard and also installed drivers for my build-in Intel network card 82579V. However I am not sure, if this driver update is required at all and the default Microsoft’s one will suffice. Anyway:

  1. Launch Device Manager and navigate to Network Adapters. Then on Power Management tab of the network card enable all “wake up” options. Also on Advanced tab enable Magic Packet.

    Enabling Magic Packet (Win PL)

  2. Navigate to Control Panel, then go into Power Options and on the left side click Choose what the power buttons do. After that go into Change settings that are currently unavailable. Finally uncheck (disable) fast-startup mode to let the PC respect the network device power settings (set in previous step).

    Disabling fast-startup (Win PL)

That’s all what is needed!


And also preserving the machine’s role in the company!

Recently I discovered that on my build server resides Visual Studio 2010 with SP1. It occupies tremendous amount of space and at the first glance it was totally unnecessary to be there at all. So I had this brilliant though and immediately went to Control Panel and hit Uninstall. Which of course failed miserably after 20 minutes of processing. Then destroyed the hard drive even more with finalization that rolled back the whole procedure…

It failed due to lack of the original .msi file, the Visual Studio 2010 Premium was installed from. Uninstaller asked me to point the location, but I am not in a possession of the DVD nor ISO anymore. Pity, because it could have saved me a lot of stress and time then. And yes, I had been warned (and even agree to take the risk) that it could leave the whole installation in an undefined state, where IDE won’t work and SP1 can’t be applied again.

My problem was not the IDE at all, but all the builds I failed to compile from now on. The message looked like this:

C:\TC.build\z-2022\Project.Dto\Project.Dto.csproj(222, 3): error MSB4019: The imported project "C:\Program Files (x86)\MSBuild\Microsoft\Portable\v4.0\Microsoft.Portable.CSharp.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.

And fixing it started to be mission critical.

Fast forwarding to the day after.

Now, let me proudly present the solution:

  1. Download the Visual Studio 2010 uninstaller from here (cached also by me here).
  2. Open command prompt and type the command:
    ./VS2010_Uninstall-RTM.ENU.exe /full
  3. Hit enter and grab a coffee as it will take some time.
  4. Then download the Portable Library Tools from here.
  5. Type the command:
    ./PortableLibraryTools.exe /buildmachine
  6. Hit enter and wait few seconds to restore everything to normal.
    Without the switch it won’t install anything until it finds VS 2010 SP1 first!
  7. Optionally, if .NET Framework seems to be dead too it might be useful to also install .NET Framework Developer Pack 4.6.2.

All green again!


By default any calls done by Qt over HTTPS will fail. This is because the OpenSSL it relies on is not included into the distribution that was installed. All you have to do, to make it work, is to download OpenSSL 1.0.xxx library for Windows from here and install to any folder (for example: “C:\OpenSSL”). The tiny 3MB package is enough. Then copy the libeay32.dll and libssl32.dll into developed applications folder (the output one) and it will be automatically picked up during startup.

There is no need to mess anything with Qt at all (and for sure no need to rebuild Qt framework!).

It was also described on StackOverflow, too.