feat(dotnet): skip injection .NET OTel packages installed#324
feat(dotnet): skip injection .NET OTel packages installed#324mmanciop merged 1 commit intoopen-telemetry:mainfrom
Conversation
560d6c8 to
e2e8392
Compare
e2e8392 to
c349abe
Compare
mmanciop
left a comment
There was a problem hiding this comment.
We should not prevent injection is the app has an OpenTelemetry API package only.
mmanciop
left a comment
There was a problem hiding this comment.
https://www.nuget.org/packages/OpenTelemetry.Api should not prevent injection.
grcevski
left a comment
There was a problem hiding this comment.
Excellent work @matt-hensley!
I just have one question related to the comment @mmanciop made, based on the latest fix to address the inclusion of the OpenTelemetry.Api package as allowed one, does that mean that if I have "OpenTelemetry.Extensions.Hosting/1.11.0" I also must have "OpenTelemetry/1.11.0" in the dependencies?
|
@grcevski Yep, it's a dependency of OpenTelemetry.Extensions.Hosting. |
|
These are the Bare{
"runtimeTarget": {
"name": ".NETCoreApp,Version=v9.0",
"signature": ""
},
"compilationOptions": {},
"targets": {
".NETCoreApp,Version=v9.0": {
"injector-deps/1.0.0": {
"runtime": {
"injector-deps.dll": {}
}
}
}
},
"libraries": {
"injector-deps/1.0.0": {
"type": "project",
"serviceable": false,
"sha512": ""
}
}
}With
|
|
@matt-hensley and @martincostello from the SIG call we had today, there was a question, is it possible that the OTEL API package (that's now allowed) to break application still if it's incompatible with the auto injected SDK? If that's the case maybe disallowing all OTEL packages is better, but if the likelihood is small then we can keep it as is. |
I have never heard of an API package being incompatible with the SDK tbh. |
@basti1302 on the call mentioned that he experienced issues while writing similar logic for Python. |
Yes but Python is a bit special. I specifically meant .NET :-) |
I see, OK. Does the change look good to you know? We can't merge even with 2 approvals because we still have your pending changes requested. Matt updated the code to allow OpenTelemetryApi. |
Let me try to break it with some preposterous combination of API and SDK. If I don't manage in the next 30m, I'll approve :-) |
Well, I was very wrong. There are combinations that break like a brick, especially with Older API + newer SDK. And issues with Geneva + OTLP exporter. This actually makes me wonder how will it work with libraries using native .NET instrumentation. I will force-push to the state where it denied injection if any OTel package was present, and will merge. With many apologies to @matt-hensley for the extra work. |
Fixes #267
Makes .NET injection more conservative by skipping auto-instrumentation when the target app already references OpenTelemetry packages.
The injector inspects the
*.deps.jsonfile of the target application when it is available. If the dependency graph already includesOpenTelemetry*, the injector skips adding .NET auto-instrumentation environment.