Dotnet publish is ignoring --runtime parameter

[iridin]

Describe the bug

Since the SDK 9.0.102 version, publishing a containerized application that is intended for multiple platforms, no longer works.
When specifying --runtime linux-x64 parameter, I can see that the dll is compiled both for linux-x64 and win-x64 platforms, subsequently causing the following error:

C:\Program Files\dotnet\sdk\9.0.102\Containers\build\Microsoft.NET.Build.Containers.targets(251,5): error :
BaseImageNotFoundException: The RuntimeIdentifier 'win-x64' is not supported by dotnet/runtime-deps:8.0. The supported RuntimeIdentifiers are linux-x64,linux-arm,linux-arm64

With .NET Core SDK '9.0.101' version and all previous (8.0.x) versions, this worked correctly, compiling only for the specified runtime.

To Reproduce

Call this command to publish the solution (while having Docker switched to Linux containers):

dotnet publish XYZ.sln --configuration Release --runtime linux-x64 /t:PublishContainer /nodeReuse:False /p:Configuration=Release /p:GeneratePackageOnBuild=True /p:ContainerRuntimeIdentifier=linux-x64

Get this output (trimmed for brevity):

XYZCommon succeeded (5,2s) → src\XYZCommon\bin\Release\net8.0\linux-x64\XYZCommon.dll
XYZCommon succeeded (0,1s) → src\XYZCommon\bin\Release\net8.0\linux-x64\XYZCommon.dll
XYZCommon succeeded (0,4s) → src\XYZCommon\bin\Release\net8.0\linux-x64\XYZCommon.dll
XYZCommon succeeded (0,2s) → src\XYZCommon\bin\Release\net8.0\linux-x64\XYZCommon.dll
XYZCommon succeeded (3,3s) → src\XYZCommon\bin\Release\net8.0\win-x64\XYZCommon.dll
XYZCommon succeeded (1,7s) → src\XYZCommon\bin\Release\net8.0\win-x64\XYZCommon.dll
XYZ failed with 1 error(s) (4,1s) → Release\win-x64\XYZ
C:\Program Files\dotnet\sdk\9.0.102\Containers\build\Microsoft.NET.Build.Containers.targets(251,5): error :
BaseImageNotFoundException: The RuntimeIdentifier 'win-x64' is not supported by dotnet/runtime-deps:8.0. The supported RuntimeIdentifiers are linux-x64,linux-arm,linux-arm64

Exceptions (if any)

Further technical details

• dotnet --info

.NET SDK:
Version: 9.0.102
Commit: cb83cd4
Workload version: 9.0.100-manifests.4a54b1a6
MSBuild version: 17.12.18+ed8c6aec5

Runtime Environment:
OS Name: Windows
OS Version: 10.0.22631
OS Platform: Windows
RID: win-x64
Base Path: C:\Program Files\dotnet\sdk\9.0.102\

.NET workloads installed:
[ios]
Installation Source: VS 17.12.35707.178
Manifest Version: 18.1.9163/9.0.100
Manifest Path: C:\Program Files\dotnet\sdk-manifests\9.0.100\microsoft.net.sdk.ios\18.1.9163\WorkloadManifest.json
Install Type: Msi

[android]
Installation Source: VS 17.12.35707.178
Manifest Version: 35.0.7/9.0.100
Manifest Path: C:\Program Files\dotnet\sdk-manifests\9.0.100\microsoft.net.sdk.android\35.0.7\WorkloadManifest.json
Install Type: Msi

[maccatalyst]
Installation Source: VS 17.12.35707.178
Manifest Version: 18.1.9163/9.0.100
Manifest Path: C:\Program Files\dotnet\sdk-manifests\9.0.100\microsoft.net.sdk.maccatalyst\18.1.9163\WorkloadManifest.json
Install Type: Msi

[aspire]
Installation Source: VS 17.12.35707.178
Manifest Version: 8.2.2/8.0.100
Manifest Path: C:\Program Files\dotnet\sdk-manifests\8.0.100\microsoft.net.sdk.aspire\8.2.2\WorkloadManifest.json
Install Type: Msi

[maui-windows]
Installation Source: VS 17.12.35707.178
Manifest Version: 9.0.14/9.0.100
Manifest Path: C:\Program Files\dotnet\sdk-manifests\9.0.100\microsoft.net.sdk.maui\9.0.14\WorkloadManifest.json
Install Type: Msi

Configured to use loose manifests when installing new manifests.

Host:
Version: 9.0.1
Architecture: x64
Commit: c8acea2262

.NET SDKs installed:
6.0.428 [C:\Program Files\dotnet\sdk]
8.0.404 [C:\Program Files\dotnet\sdk]
9.0.102 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
Microsoft.AspNetCore.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 8.0.11 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 8.0.12 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 9.0.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 8.0.6 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 8.0.11 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 8.0.12 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 9.0.1 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 8.0.6 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 8.0.11 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 8.0.12 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 9.0.1 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Other architectures found:
x86 [C:\Program Files (x86)\dotnet]
registered at [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\x86\InstallLocation]

Environment variables:
Not set

global.json file:
Not found

• The IDE (VS / VS Code/ VS4Mac) you're running on, and its version

Microsoft Visual Studio Enterprise 2022 (64-bit) - Current
Version 17.12.4

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[iridin]

This issue might be connected with this one #46015 , but I'm not sure.

[baronfel]

@iridin do you have a sample project that reproduces the error, or an https://aka.ms/binlog that you are comfortable sharing? That would let us see more directly what's going on. One immediate question I have is if you have win-x64 in your RuntimeIdentifiers or ContainerRuntimeIdentifiers at all.

[baronfel]

should be fixed by #46067

[iridin]

Thank you @baronfel for your quick response and for the fix you devised.
I was trying to create a sample project with the same build logic without all the production code, but I still don't have it ready.
We are building using the fake build script and thus we have the bin logging disabled and the build process is quite complex.

[baronfel]

Instead of having to modify your FAKE script, you can set a few environment variables and MSBuild itself will create the binlogs for you, if that's easier.

[iridin]

Yeah, thanks. Here are the build logs. Hope it helps you verify your fix.

MSBuildReproLogs.zip

[baronfel]

Yes, I think you would 100% be impacted by the bugs fixed in #46067 - your RuntimeIdentifier selection is not being correctly honored by our targets.

[baronfel]

Going to close this now that we've merged a fix. Look for it to ship in the February SDK servicing releases.

[iridin]

Thank you @baronfel for a swift fix.

[michalkovy]

I have just tested daily SDK build https://ci.dot.net/public/Sdk/9.0.103-servicing.25065.25/dotnet-sdk-9.0.103-win-x64.exe and I still see the issue. Is 9.0.103-servicing.25065.25 version expected to have the fix? Where can I find a preview/daily build of the SDK with the fix? Thanks

[baronfel]

@michalkovy the change has made it to the release/9.0.1xx branch, my suspicion is that the nightly releases aren't being updated because most servicing releases are handled 'internally' after each quarter's release.

I'll follow up on this and confirm.

[baronfel]

I confirmed that the internal builds do have the change. I can't provide those to you at this time, but you can emulate the change by copying the content of the file that I linked to above to the <SDK install root>\sdk\<version>\Containers\build location of your SDK installation.