[FEATURE REQ] Remove unnecessary package references for net 6+ TFM

[thompson-tomo]

Library name

Azure.Core

Please describe the feature.

I want package references to be framework specific so that i am not adding in un-necessary packages when functionality can be and should be provided by the framework reference. An example of such is System.Text.Json which is included in net 6

[jsquire]

//cc: @annelo-msft, @pallavit, @JoshLove-msft, @m-nash, @heaths, @christothes

[jsquire]

Hi @thompson-tomo. Thank you for opening this issue. We've been having a variation of this discussion for quite some time, but with a focus on adding additional TFMs to all packages. Thus far, we've not been able to reach consensus on that - but as this request is more narrowly scoped, I believe it's a good point for additional consideration.

Proposal

This is something that I believe would be beneficial to all Azure SDK packages, and something that we could address by updating the common build targets to remove references for packages known to be unnecessary at build time for those platforms. This would allow us to avoid the burden of downloading unnecessary polyfill packages for the majority of supported platforms.

I'd appreciate thoughts from the folks mentioned above as well as the architects. As this is a recurring request and has been in discussion for a very long time, it is something that we need to have a final decision on.

Questions and challenges

• Should we apply this to just the packages which already have explicit net6.0 targets, such as Core and Identity, to avoid having a global net6.0 target?

• Is it reasonable to detect when we're building for a known-safe platform in the common build targets so that we can tune references globally and automatically?

• Should we add the net6.0 and net461 targets to the central EngSys so that we can apply this to all packages? (this has been under discussion for quite a while without a conclusion.
  Now that we have an official TFM lifecycle, this really needs a decision.).

• Would our existing test matrix be enough to prove that any implementation is safe, or would there need to be additional work done?

References and related

• Azure SDK references packages that live in net6.0+
• Consider adding explicit net6.0 targets to all packges
• Pull request adding explicit net6.0 targets (Community contribution by @AraHaan, stalled awaiting a decision for a very, very long time)

[thompson-tomo]

Hi @jsquire

Thank you for your response. I agree that this is something which would benefit the entire sdk but was being mindful of the amount of work it would take. Also I hadn't seen the PR (#28911) which you have referenced.

My thoughts on this topic would be to review the PR as it is with the goal of accepting it based on it providing an improvement/enhancement to the current situation. A seperate issue can be created to move to centrally managing packages but low priority based on benefit gained at this point in time.

Regarding adding additional TFM, I am of the belief the main reason to add a TFM is that you need to do something conditionally based on the TFM ie add/remove packages or framework specific code.

[heaths]

• Should we add the net6.0 and net461 targets to the central EngSys so that we can apply this to all packages? (this has been under discussion for quite a while without a conclusion.
  Now that we have an official TFM lifecycle, this really needs a decision.).

Where it gets interesting is: should we still retain netstandard2.0? I think we have to. While net461 will cover everything up to net6.0 - including .NET "Core", IIRC (we tested this a few months ago in the ongoing discussions) - I don't know if that applies to every target platform e.g., Mono, though. Also, there are a few "extra" APIs declared in netstandard2.0 that aren't actually in net461, though most of those are in System.Security.Cryptography which primarily impact the Key Vault SDKs, which I've already handled.

[m-redding]

Resolved by #46637

[github-actions]

Hi @thompson-tomo. Thank you for opening this issue and giving us the opportunity to assist. We believe that this has been addressed. If you feel that further discussion is needed, please add a comment with the text "/unresolve" to remove the "issue-addressed" label and continue the conversation.

[github-actions]

Hi @thompson-tomo, since you haven’t asked that we /unresolve the issue, we’ll close this out. If you believe further discussion is needed, please add a comment /unresolve to reopen the issue.