[System.Diagnostics.DiagnosticSource] Implement metrics advice API

[CodeBlanch]

Fixes #63650

/cc @tarekgh @vishweshbankwar

[dotnet-issue-labeler]

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

[tarekgh]

CC @noahfalk

[tarekgh]

LGTM. Thanks @CodeBlanch for providing the implementation.

[tarekgh]

CC @noahfalk if need to take one final look before we merge.

[noahfalk]

I've still got concerns about the 'init' keyword :)

[noahfalk]

I've still got concerns about 'init' due to the difficulty invoking it from .NET Framework while using the officially supported 7.3 C# language version. Maybe in the future we'll decide to drop support for .NET Framework but we've not agreed to that so far.

I maintain the suggestion to define this property with as 'set', not 'init' and if we want to protect against mutations then we can make a read-only copy.

[tarekgh]

I humbly disagree. As I mentioned before, doing the allocation and copying is not good IMO especially we need to maintain that in the future too. We discussed that in the design review and didn't get any objection. Also, init is already used in the same library too.

[CodeBlanch]

The code as-is already takes a copy of the data 😄 The issue I think set creates is more that it can't be changed after the first publish of a metric. What OTel is going to do is on instrument published take the advice and construct the buckets after which point they are fixed. So having the set could just be misleading for users thinking they can set it whenever. init really conveys the meaning nicely for what this class is doing.

I guess we could have set throw based on some internal state tracking if the thing was published? But then what if you hand the same advice class to multiple instruments? 🤔

[noahfalk]

We had a fair bit of internal discussion around init and concluded that yes, we are going to use the new language feature here.

We know that the presence of init makes it less straightforward to consume from projects using older runtime versions such as .NET Framework 4.8. By default those older versions target C# language version 7.3 which doesn't support the init keyword. Our overall goal is to design new feature APIs favoring projects that also use new languages and runtimes if a tradeoff has to be made. For developers who remain on older runtime versions (such as .NET Framework) there are a couple options:

• The most conservative choice would be not to use new features at all if they require a new language version and stick with the features that were available at the time a given runtime was released.
• An alternative that I think many developers would find preferable is to target their project at a newer C# language version when needed. Although old runtimes don't support every new language feature, the compiler does do build-time error checking to prevent accidental usage of new features on runtime versions that are known to be incompatible. The .NET team also validates our features in .NET Framework test apps that invoke the new APIs using the latest C# language version. In practice we see many .NET developers update their C# language version and are very happy with the results.

[noahfalk]

The objection to init is retracted, sorry for the delay while that discussion played out. Thanks @CodeBlanch!

[noahfalk]

We had a fair bit of internal discussion around init and concluded that yes, we are going to use the new language feature here.

We know that the presence of init makes it less straightforward to consume from projects using older runtime versions such as .NET Framework 4.8. By default those older versions target C# language version 7.3 which doesn't support the init keyword. Our overall goal is to design new feature APIs favoring projects that also use new languages and runtimes if a tradeoff has to be made. For developers who remain on older runtime versions (such as .NET Framework) there are a couple options:

• The most conservative choice would be not to use new features at all if they require a new language version and stick with the features that were available at the time a given runtime was released.
• An alternative that I think many developers would find preferable is to target their project at a newer C# language version when needed. Although old runtimes don't support every new language feature, the compiler does do build-time error checking to prevent accidental usage of new features on runtime versions that are known to be incompatible. The .NET team also validates our features in .NET Framework test apps that invoke the new APIs using the latest C# language version. In practice we see many .NET developers update their C# language version and are very happy with the results.

[tarekgh]

/ba-g logged #103784 for unrelated issue. Other failures are time out.

[JamesNK]

Nice. I'll try using these next week in asp.net core. I'll provide feedback if I run into any problems.

[JamesNK]

@reyang Does opentelemetry-dotnet have an issue for consuming them?

[vishweshbankwar]

@reyang Does opentelemetry-dotnet have an issue for consuming them?

@JamesNK - FYI open-telemetry/opentelemetry-dotnet#5487