Publishing self-contained solution yields wrong system binaries in some environments

Summary:

We are facing an issue where our projects are published with wrong System.* binaries from our builders, causing the program to crash due to wrong file versions. Problem seems to stem from netstandard1.6 dependencies (that cannot be changed since they come from nuget packages in our actual solution).

Repro test project:

ContainedPublishFail.zip Attached projects is most basic scenario found. Both app and netstandard1.6 lib use System.Text.RegularExpressions.

• All our dev machines yield proper binaries and can run the app (System.Text.RegularExpressions.dll 5.0.421.11614 - 497KB).
• Our builders and non-dev machines (which might or might not have VS 2017/2019 installed, but without license so they are not in use), yield wrong binaries (System.Text.RegularExpressions.dll 4.6.24705.1 - 112KB).

Updating the library to netstandard2.0 seemed to fix the issue in our tests machines. In our actual solution all netstandard libraries are 2.0, but some nuget dependencies seem to be netstandard1.6, so it is not possible to fix it this way.

Repro steps:

1. Unzip test solution into new folder and open a terminal at the folder
2. Run dotnet restore ContainedPublishFail.sln --runtime win-x64
3. Run dotnet publish ContainedPublishFail.sln --output output --runtime win-x64 --self-contained true --no-restore
4. Run output\ContainedPublishFail.exe some123string

Expected output (same output in dev machines):

Number: 123

Actual output (in failing builders and non-dev machines):

Unhandled exception. System.IO.FileLoadException: Could not load file or assembly 'System.Text.RegularExpressions, Version=5.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The located assembly's manifest definition does not match the assembly reference. (0x80131040)
File name: 'System.Text.RegularExpressions, Version=5.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
   at ContainedPublishFail.Program.Main(String[] args)

Additional information:

We ran the restore and publish steps with detailed verbosity level (tried diagnostic but there is just too much data that needs to be redacted). logs.zip

They contain logs for both restore and publish steps. The main reason to have a restore step separately is that we use a local nuget repository, using the --source param for restore.

@vijayrkn Although this is not a web project, we do reproduce the same issue with web project publishing. Apologies if you are not the right person to ping.

[dsplaisted]

I’m not sure what would have changed, but there have been various fixes that have gone into 6.0, so one of them may have changed something here.

Instead of looking at verbose logs, it’s way better to look at binlogs. There isn’t currently a way to redact information from them, but they are also way more useful than text logs for us to investigate an issue if you can provide them. You can also create a text log at whatever verbosity you want from a binlog.

You provided a repro here so we probably don’t need a binlog, what I think we need now is confirmation of what version of the SDK you are using when this fails.

[genriquez]

Here is the dotnet info from the machine where it fails. dotnetinfo.fails.txt

Do you absolutely need testing this with rc1? I would rather not touch much the environments where we can reproduce the issue since I don’t have direct control over them.