Can't run multi-project program with different versions of the sqlite package

[livwvil]

NuGet Product Used

dotnet.exe

Product Version

dotnet 7.0.201

Worked before?

The same version everywhere working nice.

Impact

I'm unable to use this version

Repro Steps & Context

duplicate from: dotnet/sdk#36184

Describe the bug

Can't run multi-project program in docker container due to different versions of the sqlite package. However Windows can handle it.

Used container:

• docker pull mcr.microsoft.com/dotnet/sdk:7.0

Used sqlite package versions:

• Microsoft.Data.Sqlite 8.0.0-preview.2.23128.3
• Microsoft.Data.Sqlite 7.0.12

To Reproduce

1. pull https://github.com/livwvil/dotnet_issue.git
2. run docker compose up
3. see the error messege

Verbose Logs

Unhandled exception. System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.Data.Sqlite, Version=8.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'. The system cannot find the file specified.

[zivkan]

Thanks for the repro. Like many failures, there are multiple things "going wrong" here. Any one of which would have prevented this from happening.

Firstly, your dockerfile is publishing the solution file, rather than just the one project that's executed in the RUN statement. If you change the dockerfile to publish issue/issue.csproj instead, I'd expect this to work.

Secondly, the reason this is a problem is because when you run an MSBuild target on a solution, MSBuild will run that target on every project in the solution independently. It will resolve the project graph and then run the targets on the projects in an appropriate order. Therefore, it's functionally equivalent to running dotnet publish model\model.csproj followed by dotnet publish issue\issue.csproj.

Part 2A, arguments passed on the command line are what MSBuild calls "global properties", and MSBuild script can't overwrite these properties. Therefore, by specifying dotnet publish -o someDirectory on the solution, it runs publish on every project in the solution with the same -o someDirectory, and as a consequence, every project in the solution will be published to the same directory. Therefore, if you remove the -o someDirectory argument, and instead copy issue\bin\publish (or whatever the default publish path is), then again you wouldn't have a problem.

Thirdly, version 7.0.12 of the package was compiled in september, while the 8.0.0 package was compiled in March. Therefore, Microsoft.Data.Sqlite.dll from the lower package version has a newer timestamp than the same dll in the higher package version. MSBuild has semantics called "Preserve Newest", and therefore when model.csproj published the file to the publish directory, when issue.csproj was later published, the filename already existed, with a newer timestamp than what the project wanted to copy, and therefore MSBuild didn't overwrite the newer file. I created a feature request on MSBuild to add a "CopyExact", which the .NET SDK will later be able to adopt to avoid this scenario:

• [Feature Request]: Add CopyExact to compliment PreserveNewest and CopyAlways dotnet/msbuild#9350

In summary, this is an unfortunately coincidence because the lower package version is newer than the higher package version, and publishing multiple projects into the same directory causes the file with the most recent timestamp to win. I created an issue for MSBuild and .NET SDK to enable smarter semantics, but you can resolve this by avoiding publishing multiple projects into the same directory.

I'm resolving this issue as external to NuGet.