ApplicationInsights-dotnet: Dependency conflict with Eventhubs and DiagnosticSource on Cloud Service
This week I deployed a new Azure Cloud Service using the azure eventhubs package. That package has a dependency on System.Diagnostics.DiagnosticSource >= 4.5.0. After deploying I get the following error:
Could not load file or assembly 'System.Diagnostics.DiagnosticSource, Version=4.0.3.1, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference.
The fusion log doesn’t show anything useful, other than that it find 2 different versions of the dll (hence the error). I remoted into the VM and found that a bunch of Application Insights packages are deployed next to my application (which does NOT include Application Insights), and also System.Diagnostics.DiagnosticSource version 4.4.0.
My assumption so far is that Insights is being automatically deployed by azure to wrap my application and provide telemetry (even though I have turned that off) and is therefor messing with my application. The error is not fixable with assembly redirects (it either cant find the dll, or you get the manifest error), is there any else I could try or might this be caused by an issue with the dependency guidance of the Application Insights packages?
I also posted this issue on the eventhubs page.
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 20 (10 by maintainers)
We are observing “no data” issue with multiple app services. Checked with azure support team also and they suggested removing the System.Diagnostics.DiagnosticSource dll but that crashes the app since its a dependency for the event hubs library in use in our APIs.
Also, just to confirm - we want to post some of our application’s events to EventHub but also want to monitor performance of applications on app insights. Is that not possible?
@Mikhail-Pranovich even if System.Diagnostics.DiagnosticSource, Version=4.0.3.1 is deleted, it is still implicitly brought by EventHubs SDK - this is a valid scenario we need to support.