Windows support for Container SDK seems broken (with introduction of multiarch)

[wasabii]

Windows support in the Container SDK publishing support has always been a bit broken, but I believe it's now unusable as of 8.0.405 and 9.0.102.

A few recent versions of the .NET SDK have not allowed building .NET projects using the old version of the RIDs (win10-x64), saying they are not recognized.

The SDK Container support for determining the "RID" of a container image has continued to return the incorrect value (win10-x64). This is seen in at https://github.com/dotnet/sdk/blob/db555138306982287856b0aa3eba692fbe30e936/src/Containers/Microsoft.NET.Build.Containers/Registry/Registry.cs#L296C11-L303C11

That code there attempts to intuite the RID of a container image from the manifest platform information, by simply building it from the information in the manist. And it has, for awhile now, incorrectly added the major version number onto the end of win, even though these were not supported RIDs anymore.

However, there was a workaround for this: ContainerRuntimeIdentifier. This allowed you set set a separate RID for the container build vs the build itself. Thus you could set RuntimeIdentifier=win-x64 and ContainerRuntimeIdentifier=win10-x64. The build would be happy. And the Container SDK would be happy.

However, with the inclusion of the container multiarch support, this picture has changed. ContainerRuntimeIdentifier seems to no longer be indepently settable from RuntimeIdentifier. Setting it, but not setting the pluralized version, does not work: the targets file has a check that sets the pluralized version from the singularized version, but only if the user is not running inside Visual Studio. Not totally sure why this distinction is made.

<ContainerRuntimeIdentifiers Condition="'$(BuildingInsideVisualStudio)' != 'true' and '$(ContainerRuntimeIdentifiers)' == '' and '$(IsRidAgnostic)' != 'true'">$(RuntimeIdentifiers)</ContainerRuntimeIdentifiers>

And, if you DO set the pluralized version, the pluralized version is used to cause an inner build. So, putting win10-x64 into the pluralized version to make the RID matching work causes an inner build on win10-x64, which is no longer supported (see paragraph 2). And thus that breaks.

This does seem to still work inside of Visual Studio, because that sets the pluralized version, which then makes the RID matching happy, but does NOT result in an inner build (it's probably set after that determiniation is made).

So there seems to be no escape from this. The incorrect RID interpretation from Registry.cs now matters, and there seem no longer to be a work around.

@baronfel

[baronfel]

So two immediate questions here:

• Can we remove the major version from the RID-calculation you've linked when <UseRidGraph> is false?
• Can we discover why the BuildingInsideVisualStudio clause was added to the Condition you've shown - my guess is that VS support for container publishing went sideways somehow (possibly because it uses the older, less-broadly support PublishProfile mechanism...).

[baronfel]

#46067 will fix the inability to remove Windows from the containerized RIDs, but the underlying problem with RID-creation inside Registry.cs still needs to be addressed.