Specify only base image version while keeping SDK-selected image variant?

[mu88]

Hi @baronfel,

I’m using the .NET SDK Container Building Tools and want to pin the exact .NET version used for publishing a container image, without losing the automatic base-image selection logic the SDK provides.

Right now I can do this by setting:

<PropertyGroup>
  <ContainerBaseImage>mcr.microsoft.com/dotnet/aspnet:10.0.0</ContainerBaseImage>
</PropertyGroup>

This works to pin the version, but it overrides the SDK’s helpful logic for choosing the right base image variant. For example, if I disable invariant globalization:

<PropertyGroup>
  <InvariantGlobalization>false</InvariantGlobalization>
</PropertyGroup>

...it’s not enough—I also have to manually change the base image to an -extra variant:

<PropertyGroup>
  <ContainerBaseImage>mcr.microsoft.com/dotnet/aspnet:10.0.0-extra</ContainerBaseImage>
</PropertyGroup>

This means I’m taking on the responsibility to track and reflect SDK flags (like invariant globalization) in the image tag myself, which I’d rather avoid.

Question / Desired behavior

Is there a way to specify only the version (e.g., 10.0.0) and let the SDK continue choosing the correct base image variant (e.g., adding -extra when needed) based on other project properties?
Something like:

<PropertyGroup>
  <ContainerBaseImageTag>10.0.0</ContainerBaseImageTag>  <!-- Or any equivalent property that pins only the version -->
</PropertyGroup>

…while still allowing the SDK to compute the appropriate repository and variant according to the usual rules.

Follow-ups

• If there isn’t such a property today, is there a recommended pattern to achieve “pin version, keep variant auto-selection”?
• Would you consider supporting a property like ContainerBaseImageTag (or similar) that the SDK composes with its chosen base image name and variant?

Thanks in advance!

[baronfel]

There's not such a property today, but I can see where that would be useful. We already allow certain kinds of guided variation (ContainerFamily for example), and this kind of variation is pretty aligned with that same thought process. A new property like ContainerBaseImageVersion could make sense to allow you to more directly control just this part.

All of the complexity of this decision-making is part of the ComputeDotnetBaseImageAndTag Task, so it should be very possible to

• introduce the new property in the container Targets
• add it to the set of input parameters to this Task
• update the Task to use the user-provided value if any as the 'version' part of the base image tag generation
• update tests for the Task to verify that the value overrides the version part but still allows for the rest of the inference process to occur

[mu88]

That sounds very promising, thank you for considering it 🙂

Is there anything that I can assist you with? Shall I raise a dedicated issue, or is this discussion enough for you? And is there any workaround as of now?