-
Notifications
You must be signed in to change notification settings - Fork 5.1k
fix: Partially fixed the dependency mess #38885
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
Conversation
|
Thank you for your contribution @svrooij! We will review the pull request and get back to you soon. |
Never using CodeSpace again for this project
|
Hi @svrooij. Thank you for your interest in helping to improve the Azure SDK experience and for your contribution. We've noticed that there hasn't been recent engagement on this pull request. If this is still an active work stream, please let us know by pushing some changes or leaving a comment. Otherwise, we'll close this out in 7 days. |
|
I cannot complete this PR by myself. The dependencies are a really big mess in all Azure libraries. I guess the team has to decide if they still want to support old unsupported frameworks like In my opinion the dependencies should not be configured as lowest supported but as latest available. Like a dependency upon |
|
Hi @svrooij. Thank you for your interest in helping to improve the Azure SDK experience and for your contribution. We've noticed that there hasn't been recent engagement on this pull request. If this is still an active work stream, please let us know by pushing some changes or leaving a comment. Otherwise, we'll close this out in 7 days. |
|
This is still an issue, that I would like to see resolved. I'm however not able to solve this without touching all the projects |
|
This is not my issue to solve, but the azure team should still chase this issue. |
Fixed #38857
Since the main library supports so many target frameworks it's a hassle to manage all the dependencies. Accepting this PR will probably break stuff.
Reduce dependencies
Azure.Core has dependencies upon System.Text.Json (with all those specific versions based on the correct framework). So any project depending upon Azure.Core, will also get the correct version of System.Text.Json. By reducing the PackageReferences to packaged already referenced by a dependency this will also simplify things.
My suggestion is to adjust the
Packages.Data.propsfile to keep the dependencies in line for all the specific frameworks. I propose an ItemGroup per target, to keep all the dependencies equal per target framework and have those projects use the latest and greatest that platform has to offer. Building an app in .net 7 should not be using System.Text.Json version4.7.2a three year old version without all the recent improvements the dotnet team has made.I would even go as far as saying you should add this code the
Packages.Data.propsfile, This means people building apps on net6.0 or net7.0 wont get the unneededMicrosoft.Bcl.AsyncInterfaces:Drop support for end-of-life targets
And maybe even start considering dropping support for all those versions that are out off support for years, according to your own support policy:
.NET Core 2.1ended support Augustus 21th 2021 which is over 2 years ago..NET5ended support May 10th 2022 which is also over 16 months ago.NET 4.6.1ended support on April 26th 2022 according to this page which is 17 months ago.Remove high severity vulnerabilities
Packages.Data.props seem to be forcing
<PackageReference Update="Newtonsoft.Json" Version="10.0.3" />which according to nuget has at least 1 high severity vulnerabilityContributing to the Azure SDK
Please see our CONTRIBUTING.md if you are not familiar with contributing to this repository or have questions.
For specific information about pull request etiquette and best practices, see this section.