Wraith

[bench_result_7600K.zip](https://github.com/Alan-FGR/minECS/files/2251203/bench_result_7600K.zip)

[native_result_7600K.zip](https://github.com/Alan-FGR/minECS/files/2251222/native_result_7600K.zip)

What is blocking this? Making this optional and configurable in a natural way in the .net instrumentation is blocked by this issue being in limbo. https://github.com/open-telemetry/opentelemetry-dotnet-contrib/issues/1954#issuecomment-2231884662

> * We would take a dependency on Microsoft.Data.SqlClient then? It seems ok conceptually (we're providing instrumentation for it!) but need to figure out how to correctly support apps on...

At the moment what I'm working on is translating the unnamed objects in the SqlClient library to be strongly typed. That will allow us to be trim compatible but doesn't...

> @Wraith2 Would Ms.Data.SqlClient be open to this approach? Probably. Note that I'm an external contributor and I don't make any decisions. I've found that in general as long as...

As long as the strongly typed diagnostic objects that I introduced are working through the current adapter code I think this can be closed.

in https://github.com/dotnet/SqlClient/pull/2226#issuecomment-1914033445 @mbakalov checked the changes were compatible with otel and app insights. I expect that the sqlclient team are just waiting on major version processes before merging.

https://github.com/dotnet/SqlClient/pull/2226 is merged and will be in the next preview build of SqlClient.

> I'm also curious about whether constants for the keys would be better. Using one of the existing constants would require that I add a project reference to the OpenTelemetry.SemanticConventions...