BUG: SDK-3.1.300 dotnet publish .sln now chooses the older DLL in version conflict

SDK 3.1.300 shows a different behavior when running dotnet publish on the solution file.

3.1.300 now selects the lowest versioned DLL when there is a version conflict between projects. This causes the projects depending on the newer DLLs to break, where the old bevhavior usually is expected to work fine due to a >= version dependency. We have seen this behavior both on direct package dependencies, but also on implicit dependencies from installed packages.

SDK 3.1.202 and earlier work as expected by selecting the most recent version of the two conflicting DLL versions to the publishing directory.

I have uploaded an example repository to demonstrate the behavior with a Modern App with a dependency on Newtonsoft.Json 12.0.x living in the same solution as a Legacy App with the same Newtonsoft.Json dependency targeting the older 10.0.x version. Project can be found here: https://github.com/vidarw/dotnet-sdk-3.1.300-nuget-issue

docker run --rm -it -e /bin/sh -v C:\source\dotnet-sdk-3.1.300-nuget-issue:/app mcr.microsoft.com/dotnet/core/sdk:3.1.300
cd /app
dotnet publish -o ./3.1.300-docker

vs.

docker run --rm -it -e /bin/sh -v C:\source\dotnet-sdk-3.1.300-nuget-issue:/app mcr.microsoft.com/dotnet/core/sdk:3.1.202
cd /app
dotnet publish -o ./3.1.202-docker

and compare the version of the dlls. In my example the Newtonsoft.Json.dll will return 12.0.3 in 3.1.202 and 10.0.3 in 3.1.300 respectively.

The expected behavior is to get the most recent version in the published directory. If the change in behavior for some reason is intentional - a warning should be added to the console output.

[vidarw]

Come on… This is clearly a issue that should be handled by the SDK/compiler in some way or form?

I certainly understand that the problem is caused by stupid build practices - but it should at least produce a warning when you dotnet publish a solution file (which is after all a valid input) using the -o parameter or produce visible warnings to the user when DoubleWrites are detected?

[dsplaisted]

I agree we should fix something with the -o option and solution files. I thought we had other issues tracking that, but when I looked I found various related issues but not one specifically for -o and solution files, so I filed #15607.

@Erythnul If you can share more details along with a binlog or a repro of your issue I can take a look. Are you specifying an output path as a command-line parameter when building the solution? What’s the incorrect behavior you’re seeing?