Please clarify 'A singleton instance of TelemetryClient is already registered in the DependencyInjection container'

[iamalexmang]

I am not seeing the same experience in regards to dependency injection.
According to the article, 'A singleton instance of TelemetryClient is already registered in the DependencyInjection container'.

However, after adding Application Insights to the services collection, I am NOT seeing a TelemetryClient object properly registered. Let me clarify: an object of type Telemtryclient does get resolved, but it does NOT contain the properties configured with the ApplicationInsightsServiceOptions objects passed in as a parameter to the AddApplicationInsightsTelemetry extension method.
To be clear: it doesn't even contain an Instrumentation Key value.

This would suggest that I have to configure a TelemetryClient singleton myself, but that would go against the deprecation of the TelemetryClient constructor.

Is this a bug, or is the doc too obscure to explain how to achieve a proper dependency injection experience?

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 4b88d8c4-0013-70aa-7997-a2203afd9743
• Version Independent ID: 0ab99d5e-4ebd-8cb9-3d27-efe58def249f
• Content: Azure Application Insights for ASP.NET Core applications - Azure Monitor
• Content Source: articles/azure-monitor/app/asp-net-core.md
• Service: azure-monitor
• Sub-service: application-insights
• GitHub Login: @mrbullwinkle
• Microsoft Alias: mbullwin

[iamalexmang]

For context:

[mrbullwinkle]

adding @cijothomas for comment.

[cijothomas]

To be clear: it doesn't even contain an Instrumentation Key value.

This is incorrect. Intrumentation key is there, inside the TelemetryConfiguration part of TelemetryClient.
Its not set on TelemetryClient.Instrumentation, and is not required.

[cijothomas]

The TelemetryConfiguration inside TelemetryClient is the exact same one used for all the other telemetry. There is no "public" method to see it, and it is by design. If you are in a debugger, you can examine it.

[iamalexmang]

Thanks for the reply.
I'm disappointed by your harsh and unverified reply.

Maybe you would care to explain "the TelemetryConfiguration inside TelemetryClient is the exact same one used for all the other telemetry".
Especially in context to this: an injected TelemetryClient and an injected TelemetryConfiguration. Supposedly "same".

[cijothomas]

If you think my replies are harsh and unverified - its best for me to not comment further. Sorry.

[iamalexmang]

Repsectfully, asking me on two repos and three threads to elaborate the issue, having it elaborately explained with reproductiok steps, screenshots and references just to then reply almost instantaneously “this is incorrect. The instrumentation key is there” when it is clearly not, is disapointing to say the least. Get Outlook for iOS<https://aka.ms/o0ukef>

…

________________________________ From: Cijo Thomas <notifications@github.com> Sent: Thursday, July 23, 2020 6:13:58 PM To: MicrosoftDocs/azure-docs <azure-docs@noreply.github.com> Cc: Alex Mang <amang@keyticket.eu>; Author <author@noreply.github.com> Subject: Re: [MicrosoftDocs/azure-docs] Please clarify 'A singleton instance of TelemetryClient is already registered in the DependencyInjection container' (#59590) If you think my replies are harsh and unverified - its best for me to not comment further. Sorry. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#59590 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABMBPYJHAI5OXWZF67J6CL3R5BHTNANCNFSM4PFUKMPQ>.

[mrbullwinkle]

@iamalexmang apologies for the confusion, had I seen your GitHub Issue on the SDK repo: microsoft/ApplicationInsights-dotnet#1972 I would have just added a cross link to the issue rather than looping the engineering team into the doc issue which did not have the same level of detail. I saw your link to the closed issue, but in glancing at it I thought you had created only a new issue against the docs, I suspect the engineering team made the same error.

We often have customers who will accidently open non doc issues against the docs repository and I assumed that was the case in this instance rather than the reality that you had a more detailed issue already created against the SDK repository.

In this case to avoid further confusion, it is probably easier to have this: microsoft/ApplicationInsights-dotnet#1972 be the only open issue on this topic. If the engineering team determines there is a bug that needs to be fixed or something that needs to be addressed in docs we can reopen this issue at that point and take action on the docs side.

As far as the brevity of responses I can assure you its just that we only have a very finite amount of time to answer questions on GitHub and sometimes that means we try to triage and respond quickly. When I looped in the engineering team you weren't getting some random support person you were getting one of the people who wrote and maintains the SDK and is the expert on how it works. We really appreciate you taking the time to give us feedback, and appreciate your patience.

I am going to close out this issue in the interim until the engineering team has a chance to your review your more detailed question on the SDK repo. Thanks again, and my sincere apologies for adding to the confusion, by not having closely read your cross-link to the closed issue.

[mrbullwinkle]

#please-close