Consider adding explicit net6.0 targetFramework outputs for all clients

[christothes]

Library name

Azure.Core

Please describe the feature.

From this customer issue

Consider targeting newer frameworks to reduce client dependency sets. For any packages which have been absorbed into the framework this is safe and compatible. We can also potentially benefit by using the new API and functionality available in those new frameworks.

PS: The only place to be careful about this is with packages like Microsoft.BCL.AsyncInterfaces -- those were not absorbed by the framework and need to remain exposed -- or even better if you ever use them try to avoid exposing them by using PrivateAssets="Compile"

[AraHaan]

Sad we cant look into alternatives to Microsoft.BCL.AsyncInterfaces that are built into the framework.

[AraHaan]

Oh interesting:

I guess for .NET an experiment could be done to see if the Azure SDK will compile without the reference on .NET Core/5 and 6+ TFMs. That dependency might just be adding type forwards to everything in it to things in System.Runtime.

[ViktorHofer]

I guess for .NET an experiment could be done to see if the Azure SDK will compile without the reference on .NET Core/5 and 6+ TFMs. That dependency might just be adding type forwards to everything in it to things in System.Runtime.

Correct. Microsoft.Bcl.AsyncInterfaces is just a facade when used on any tfm that's compatible with netstandard2.1 (.NETCoreApp mainly): https://github.com/dotnet/runtime/blob/e3860440c151897968eca2227ae98c1912580c44/src/libraries/Microsoft.Bcl.AsyncInterfaces/src/Microsoft.Bcl.AsyncInterfaces.csproj#L15.

I don't have full context on what your clients currently target but the Microsoft.Bcl.AsyncInterfaces package should only be required when targeting .NETFramework or .NETStandard < 2.1.

[pallavit]

@christothes given our latest conversation on target frameworks - do you still see this as a valid concern?

[github-actions]

Hi @christothes, we deeply appreciate your input into this project. Regrettably, this issue has remained unresolved for over 2 years and inactive for 30 days, leading us to the decision to close it. We've implemented this policy to maintain the relevance of our issue queue and facilitate easier navigation for new contributors. If you still believe this topic requires attention, please feel free to create a new issue, referencing this one. Thank you for your understanding and ongoing support.