Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deprecating TelemetryConfiguration.Active singleton #1152

lmolkova opened this issue Jun 8, 2019 · 5 comments


Copy link

@lmolkova lmolkova commented Jun 8, 2019

With ApplicationInsights SDK 2.11-beta1 we are deprecating TelemetryConfiguration.Active on .NET core apps, see #1148.

ApplicationInsights exposes TelemetryConfiguration.Active singleton to enable auto-configuration scenarios in the absence of a dependency injection framework.

It is used on ASP.NET Classic apps (in Microsoft.ApplicationInsights.Web SDK). The configuration is read from the ApplicationInsights.config file by auto-collectors when an application starts.
User can access configuration that is used by auto-collectors and is able to customize it.

It is not the case for ASP.NET Core application where Dependency Injection is part of the framework - ApplicationInsights configuration is done and could be accessed and customized through DI container. The details and examples could be found here;

Active singleton creates issues typical for static singletons - lifetime it tight to process, testing is complicated. This is especially problematic in ASP.NET core apps, Azure WebJobs, and generic host apps, where one process may host multiple applications. So there ApplicationInsights SDK configures an instance of TelemetryConfiguration per host. It frequently results in confusion around which instance of configuration to use: one in the DI container or Active.


This comment has been minimized.

Copy link

@macrogreg macrogreg commented Aug 6, 2019

@lmolkova In the context of this change, what is the recommended replacement for the popular pattern of creating an instance of TelemetryClient via the parameter-less ctor at multiple places, instead of carrying around an instance?
Will TelemetryClient() use something other than TelemetryConfiguration.Active?
If so - what? If not - what is the recommendation? I was that doing

var client = TelemetryClient();

at multiple places is a very common usage pattern.



This comment has been minimized.

Copy link
Contributor Author

@lmolkova lmolkova commented Aug 6, 2019

In console apps, where ApplicationInsights SDK or AppInsights ILogger provider are used, get TelemetryConfiguration instance from the DI container and create TelemetryClient whenever you want.

Check out how you can customize configuration for ILogger provider and ASP.NET Core SDK

When building container yourself, you decide how to customize the configuration and register it in the container. The baseline: you can just register TelemetryConfiguration instance and still use dependency injection to resolve it. Pay attention to nuances like

  • when registering an instance without a factory, an instance is not disposed with the host, so always use factories to register disposable instances
  • use services.Configure<TelemetryConfiguration>, but be careful with correlation and add OperationCorrelationTelemetryInitializer to ensure correlation still works:
     (o) => {
       o.InstrumentationKey = "123";
       o.TelemetryInitializers.Add(new OperationCorrelationTelemetryInitializer());

If you don't want to use DI, and have pure console app, create config once and pass it around however you want.

When creating configuration instance yourself, use TelemetryConfiguration.CreateDefault() and not the parameterless constructor (to enable correlation):

var config = TelemetryConfiguration.CreateDefault();
var client = new TelemetryClient(config);

Keep one TelemetryConfiguration per app lifetime (a few is also fine), but you may create as many clients as you want.
Do not forget to dispose TelemetryConfiguration when gracefully shutting down the application.


This comment has been minimized.

Copy link

@pharring pharring commented Aug 6, 2019

I think we advise using IOptions<TelemetryConfiguration> instead of a raw TelemetryConfiguration instance. At least that's what you get with the ILogger extension.

If building the DI container yourself, of course you're free to do whatever you want, but I think we prefer services.Configure<TelemetryConfiguration>(...) over services.AddSingleton<TelemetryConfiguration>(...).


This comment has been minimized.

Copy link
Contributor Author

@lmolkova lmolkova commented Aug 6, 2019

yes, thanks for the clarification, @pharring, update comment above


This comment has been minimized.

Copy link

@bjornharrtell bjornharrtell commented Oct 31, 2019

I've used TelemetryConfiguration.Active to programmatically configure the configuration used with Microsoft.ApplicationInsights.NLogTarget. From the above information, it's not clear to me what the rewrite strategy should be in the case of Microsoft.ApplicationInsights.NLogTarget.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
5 participants
You can’t perform that action at this time.