Closed Uight closed 2 months ago
In our company we migrated to NUnit 4 by
I personally did it on more than 60 test projects and it went smoothly.
Now, we can nevertheless proceed in 2 steps:
I can take care of that Sounds reasonable? Cheers A
@Adhara3 so i update everything expect the nunit stuff now and youll update the nunit stuff later? In that case ill probably create a PR after the target framework stuff is done to avoid conflicts in the .csproj files
Or do you do everything because just updating the other nugets is work for a few seconds anyways.
Closed with #79
We currently have this package or better said a fork of it (which is why the whole code is checked) in an unapproved feed in our company. These feed is checked for security and license stuff to allign with FOSS List requirements and the new european security stuff but that just as a note.
The fork was flagged for using Newtonsoft.Json in a version lower than 13.01 for: https://security.inedo.com/vulnerability/details/PGV-2245804?utm_source=proget&utm_medium=product&utm_campaign=proget23_preview
Newtonsoft.json is implicitly used by Microsoft.NET.Test.Sdk (17.3.0) in version 9.0.1 The package itself is fine as all teh dependencies (nugets) are only for the testing stuff which is not part of the package
I think this should still be resolved by updateing Microsoft.NET.Test.Sdk to 17.11.0 which then uses a compliant version of Newtonsoft (13.01)
Im not to sure if the other packages would need updating too because some of them use old versions but as for Nunit updating can be a pain with some assert being removed and only available as classic asserts. And yes i just checked that updating nunit would cause pretty much every assert to fail so i would stick to just updating the Test SDK.
Other opinions?