Configuration reading should be resilient and easy to troubleshoot about applicationinsights-dotnet HOT 4 CLOSED

I was facing the same issue as mschmeller in https://github.com/Microsoft/ApplicationInsights-Home/issues/23. And like him, I too was overriding the instrumentation key with one stored in the web.config via the Global.asax. Everything worked fine locally but bombs out when it was deployed to azure.

In my case, it turned out that Azure did not like the use of WebConfigurationManager in this context. I switched my code from:

Microsoft.ApplicationInsights.Extensibility.TelemetryConfiguration.Active.InstrumentationKey = System.Web.Configuration.WebConfigurationManager.AppSettings["MyInstrumentationKey"];

to

Microsoft.ApplicationInsights.Extensibility.TelemetryConfiguration.Active.InstrumentationKey = System.Configuration.ConfigurationManager.AppSettings["MyInstrumentationKey"];

and everything seems to work as expected.

I hope this helps.

from applicationinsights-dotnet.

Are you sure this issue is related to the wrongly set instrumentation key? My guess would be that you still have some bad telemetry initializers in configuration file. If the code in the first snippet fails you'll not initialize InstrumentationKey, but TelemetryChannel will be not null. So you should not get NullReferenceException.

from applicationinsights-dotnet.

Same problem with mismatched property names. In TelemetryProcessors, if there's a property referenced in the .config that doesn't exist in the code, the SDK silently fails to send any telemetry at all.

from applicationinsights-dotnet.

Another problem happens when unit test project doesn't have reference to some of the modules like DependencyCollector and the call to new TelemetryClient() fails with TypeLoadException.

from applicationinsights-dotnet.