Darn!

Really nice work

I am also not sure what the support policy of non-current versions of packages are (from Microsoft).

Just because there is STJ 9.0.1 doesn’t necessarily mean STJ 8.0.4 is outdated.

And yes, direct deps override transitive ones - but that shouldn’t be used to workaround a CVE

That is the funny part - People (including Microsoft) did push out new version still having outdated dependencies.

So even if you as a responsible dev, did you job and keep everything up to date, you would not have been done.

Hmm that might be - never thought of that.

Maybe it is laziness. Every ide makes it somewhat easy to upgrade all your packages in one go.

Central Package Management makes this even more trivial

When you say it - I can remember some discussion going on, on the GitHub repo. And basically, as you can always override such issue with a direct dependency it wasn’t crtitical.

Personally - I don’t like that because it doesn’t lead developers to a „pit of success“

Understandable - but you will face the issue probably in November this year again :)

And I am still not sure why the issue comes in the first place. It might be worth reporting this over at the nuget repo.

I mean, given that even netstandrd2.0 would support the v9 version of the dependency

Well - that is a good question.

We faced similar issues with the System.Text.JSON - where even many MS packages didn’t update STJ to fix the CVE (even though the package itself got updated).

Interesting - for sure there are man corner cases where this might not work.

Thanks for the update

Interesting - that would also move the validation whether or not services can be created to compile-time (not in all cases, but in many) !?

As direct deps are always overruling transient deps, users can override the package. But the other way around doesn't work.

Yes, there is a risk that it breaks your library code, though.

We in bUnit took your last approach.
We aligned TFM with the package version, see: github.com/bUnit-dev/bU...

I also did this in some of my other smaller libraries.
For netstandard2.0, I would roll with the lowest required version - so 8.0.1 for your dep.

Highres version: steven-giesel.com/blogPost/004...