BASIC DESCRIPTION/CONFIGURATION:
We have a .Net Framework 4.6.1 (based upon ServiceStack) WebAPI hosted as Azure WebApp in the Cloud. Each release-version of our API gets its own Application Insights telemetry endpoint, but we never activate Application Insights for our project in Visual Studio. Instead, after swapping a new releasable version from the staging to the production slot, we activate Application Insights via the Azure Portal, and by that we automatically receive all the request-telemetry that we need out of the box. In the configuration section of our WebApp I can see that some AI-specific Keys were added, most importantly the “APPINSIGHTS_INSTRUMENTATIONKEY”.
This used to work fine. Now I had to implement a feature to be able to send some custom information from our code to application insights. Herefor I added the Microsoft.ApplicationInsights NuGet package (2.13.1) to our project. In our first scenario I send a custom exception via:
_telemetryClient.TrackException(…)
To test the new feature I created a Development Application Insights resource in the cloud and added the corresponding instrumentation key to our app.config. This works as expected and I can see the exception which I send here in the AI-Instance in the cloud.
NOW THE PROBLEM:
When I publish the app with the new feature to the staging slot in the cloud an then activate application insights via the portal, then I do not receive any standard request-telemetry data any more, only my custom exceptions.
1.) How is request data collected anyway when activating AI via the portal? I cannot find any dlls which would be added to our app hereby, so I suppose that the IIS-Server which hosts our web app collects and transmits the data?
2.) Does the server detect that there is a Microsoft.ApplicationInsights.dll in our code and by that stop collecting the request data because it expects that we handle this in our code ourselves?
The main reason why I do not want to simply activate the full-stack Application Insights feature for our project in Visual Studio is, that it installs a lot of dependencies which trigger DLL-Hell because we need some older versions for these dlls for other dependcies in our app (System.Net.Http for example)