When publishing a .net core console application (.Net Core 3.1) for release many errors are issued similar to the following.
Detected package downgrade: System.Threading from 4.3.0 to 4.0.11. Reference the package directly from the project to select a different version.
ProjectABC.Services -> log4net 2.0.8 -> System.IO.FileSystem 4.0.1 -> runtime.win.System.IO.FileSystem 4.3.0 -> System.Threading (>= 4.3.0)
ProjectABC.Services -> log4net 2.0.8 -> System.Threading (>= 4.0.11)
I understand that nuget resolves to the lesser version in this case (4.0.11) even though it breaks the other dependency (>= 4.3.0) because of the nearest-wins concept.
Is there any setting or configuration for this instead to resolve the newest version that meets the conditions of all?
In this case version 4.3.0 as it is >= 4.0.11 and >= 4.3.0
What was the benefit by not doing this and resolving with nearest-wins instead, as it does now?
Most solutions seem to go with adding the newer version of the dependency directly to the project to fix the error. As it satisfies the nearest-wins rule. This seems cumbersome to maintain though and easy to accidentally leave unneeded dependencies if they are not directly needed by the project and log4net (in this example) was ever removed or replace.
Possible Worksarounds
Some other suggestion seem to include changing the configuration to not treat the "NU1605" warning as Error, or setting the target runtime to Portable (currently I am building for win-x64).
I have been unable to have VS save the configuration after removing the "NU1605" warning from the "Treat warnings as errors" input, and manually changing the .csproj file has had no effect.
So I am assuming there is a technical reason that these warnings need to be treated as errors when publishing?
Setting the target runtime to Portable does seem to stop the error from being produced when publishing. My understanding of this is that at runtime the wrong version of the dependency will still be used based on nearest-wins, the warnings and errors are only skipped though as the full compilation is delayed. So by chance everything may work or break if a component was added between (4.0.11) and (4.3.0) to the dependency that is needed. Is my understanding of this accurate?
The main questions I am trying to answer are.
Is there any alternative to directly adding the newer version of the dependency to the project, that would still cause the correct version to be resolved at compile time?
Is changing the target runtime to portable actual fixing the error or just delaying it until runtime?