-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider adding explicit net6.0 targetFramework outputs for all clients #28492
Comments
Sad we cant look into alternatives to |
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. |
Signed-off-by: AraHaan <[email protected]> Fixes Azure#28477. Fixes Azure#28492. Fixes Azure#28577.
@christothes given our latest conversation on target frameworks - do you still see this as a valid concern? |
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. |
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"
The text was updated successfully, but these errors were encountered: