Recently I had to get my hands dirty with some Application Insights code. As it turns out, putting AI to work in your non-web, .Net Framework application is not as easy as in an Asp.Net Core vCurrent microservice. Who would've guessed?! Anyway, here are a few notes that I wish I had a few weeks ago.

Microsoft.ApplicationInsights.WorkerService

Yes, that's your friend if you're not using .Net core. Basically it does the same when you register with your ServiceCollection, but it leaves out some Asp.net Core specific stuff. It's a separate nuget package of course, you just need to be aware of it.

WCF bindings that aren't HTTP/Soap won't work

Yeah, my net.tcp/binary/gzip protocol did not pick up parent activities. You need to implement an IClientMessageInspector and see if there's an Activity.Current, and if so, inject a custom header into the message in BeforeSendRequest. On the server-side, implement IDispatchMessageInspector and extract the header - and put in somewhere in context. Then you can start up a new Operation-trace using said Activity.Id as parent.

Distributed tracing doesn't work with "local sampling"

If you're running AdaptiveSampling = true, or some sort of fixed sample rate - there will be no guarantee that traces are sampled in both ends of your cross-application trace. There's just not, because the Application Insights TelemetryClient implements tail-based sampling - which means that the decision to sample a trace, is taken when the trace is finished. So the trace-flag (0 = None, 1 = Sampled) is always 0, when you call any dependency. This sucks. This github issue addresses it, but who knows when they get around to implementing it.

If you disable Adaptive Sampling and do not specify samplerate,  Application Insights will sample your traces at the ingestion point, thus making sure that if an operation is sampled, then all parts of it will be available in the interface. But I don't think it's cool to send potentially 20x more data to Azure, to make this work