Failed to use basic images correctly

[Varorbc]

I was getting ready to build a multi-architecture image, but I noticed it wasn't using the correct base image. Instead, it defaulted to the dotnet/aspnet image. Here are the steps to reproduce the issue.

By the way, I noticed that the image tag is x64 instead of amd64. It would be great if we could use amd64 instead of x64.

Reproduce steps

1.WebApplication1

<Project Sdk="Microsoft.NET.Sdk.Web">

  <PropertyGroup>
    <TargetFramework>net9.0</TargetFramework>
    <Nullable>enable</Nullable>
    <ImplicitUsings>enable</ImplicitUsings>
    <ContainerImageTag>1.0.0</ContainerImageTag>
  </PropertyGroup>

  <Target Name="PreBuild" BeforeTargets="PreBuildEvent">
	<Exec Command="echo 'PreBuild ContainerBaseImage:$(ContainerBaseImage) ProcessorArchitecture:$(ProcessorArchitecture)'" />
  </Target>
  
  <Target Name="PostBuild" AfterTargets="PostBuildEvent">
	<Exec Command="echo 'PostBuild ContainerBaseImage:$(ContainerBaseImage) ProcessorArchitecture:$(ProcessorArchitecture)'" />
  </Target>

</Project>

2.Directory.Build.targets

  <Project>

	<PropertyGroup Condition="'$(ProcessorArchitecture)' == 'amd64'">
	  <ContainerBaseImage>mcr.microsoft.com/dotnet/sdk:9.0.200-alpine3.20-amd64</ContainerBaseImage>
	</PropertyGroup>

	<PropertyGroup Condition="'$(ProcessorArchitecture)' == 'arm64'">
	  <ContainerBaseImage>mcr.microsoft.com/dotnet/sdk:9.0.200-alpine3.20-arm64v8</ContainerBaseImage>
	</PropertyGroup>

  </Project>

3.

dotnet publish -v n -t:PublishContainer -p RuntimeIdentifiers=`"linux-x64`;linux-arm64`" > build.log

[Varorbc]

@baronfel Can you help me take a look?

[baronfel]

For multi-arch builds, the base image to use is decided at the 'outer' build layer (where ProcessorArchitecture=msil) and is then passed down into the individual architecture-specific builds. You should probably be doing something like

<ContainerBaseImage>mcr.microsoft.com/dotnet/sdk:9.0.200-alpine3.20</ContainerBaseImage>

without Conditions in your project file - the SDK tooling takes case of finding the arch-specific variants of that 'image manifest' for you. I just confirmed this testing with your examples.

[Varorbc]

For the building of multi - architecture images, its processor architecture is msil. But when it comes to the individual architecture - specific builds, aren't they amd64 and arm64? And since I have used conditions, shouldn't they use my specific base images? Isn't that how it's supposed to be understood?

[baronfel]

What you describe is one way to implement it, but it is not the way we have chosen - we preferred to implement a mechanism that ensures all arch-specific images must be part of the same parent base image, to help ensure that when we stitch together the arch-specific images into one multi-arch manifest the only difference between the images is the architecture.

In your example above, you can see that there is already some drift between your two sub-images - they use different OS versions. This is generally not a good thing - the same named image should have all of the same configuration except for the architecture difference.

[Varorbc]

I'm sorry, the example I gave above wasn't very good because I used different system versions. I've already updated the example. Actually, what I want to demonstrate with my example is the use of base images for different architectures, rather than a single unified base image.

[baronfel]

I don't believe we support that now - by design. Can you tell me more about when having different base images would be desirable for you? What technical benefits do you get out of it? As far as I've seen, it's kind of an anti-pattern around the container ecosystem.

[Varorbc]

Well, you see, before we only released single - architecture images, and we didn't create any statements about it. That's because in many of our previous projects, we used different base images according to the different processors. But now, when we use the SDK to release multi - architecture images, we find that the base image is not what we expect it to be.