TrackException is bleeding a console or trace value into test output

[RickStrahl]

Repro Steps

When calling AppInsights.TrackException() a single numeric value bleeds out into the the output console when testing and also during debug sessions. This is likely a debug value, but still it's not cool to see this value bleed through in debugging and test sessions since it has no context.

Actual Behavior

I'm demonstrating with the Console.WriteLine() calls to wrapper the test output around the call to TracException. I also see this in the debug window and I've been wondering in the past where this errant value in my debug output was coming from and it turns out it's AInsights.

Expected Behavior

No bleeding of output. This odd value shows up in trace output while debugging.

Version Info

SDK Version :
.NET Version : 4.6.2
How Application was onboarded with SDK(VisualStudio/StatusMonitor/Azure Extension) :
OS : Windows 10 (latest stable)
Hosting Info (IIS/Azure WebApps/ etc) : Desktop app

[pharring]

I don't think this is coming from the SDK. Can you create a self-contained repro? I tried the obvious thing below and I didn't see any rogue values. I'm using the latest SDK built from the develop branch.

using System;
using System.Collections.Generic;
using Microsoft.ApplicationInsights;
using Microsoft.ApplicationInsights.Extensibility;

namespace ConsoleApp1
{
    class Program
    {
        static void Main(string[] args)
        {
            var config = new TelemetryConfiguration("<your instrumentation key>");
            var client = new TelemetryClient(config);
            try
            {
                throw new Exception("oops");
            }
            catch (Exception ex)
            {
                Console.WriteLine("1");

                client.TrackException(ex, new Dictionary<string, string>
                {
                    ["exmsg"] = ex.Message,
                    ["exsource"] = ex.Source,
                    ["extrace"] = ex.StackTrace
                });

                Console.WriteLine("2");
            }
            finally
            {
                config.Dispose();
            }
        }
    }
}

[RickStrahl]

Ugh - thank you. After a bunch of digging I found that indeed the bleed is coming from of my own old library components.

Apologies for the false alarm.