Support RuntimeFrameworkVersion to infer image tag version

[scrocquesel-ml150]

Actually, the image tag is build from the TargetFramework and use stable tag.

 <TargetFramework>net7.0</TargetFramework>
 <!--  with only TargetFramework
 <ContainerBaseImage>mcr.microsoft.com/dotnet/runtime:7.0</ContainerBaseImage>
-->
<RuntimeFrameworkVersion>7.0.9</RuntimeFrameworkVersion>
 <!-- 
<ContainerBaseImage>mcr.microsoft.com/dotnet/runtime:7.0.9</ContainerBaseImage>
 -->

Something like

<Target Name="ComputeContainerBaseImageTagOverride" Returns="$(_ContainerBaseImageTag)"
    DependsOnTargets="_ComputeContainerBaseImageTag" BeforeTargets="ComputeContainerBaseImage">
    <PropertyGroup>
      <_ContainerBaseImageTag Condition="'$(RuntimeFrameworkVersion)' != ''">$(RuntimeFrameworkVersion)</_ContainerBaseImageTag>
    </PropertyGroup>
  </Target>

[baronfel]

This is a great idea - would you be interested in contributing it? I just checked and it looks like this is valid for all of the container images that we current make in dotnet/dotnet-docker. It also aligns with the observed tags at https://mcr.microsoft.com/en-us/product/dotnet/aspnet/tags, for example. @richlander is this property/association a valid one to make? If so it would simplify some of our inference logic nicely.

[scrocquesel]

Seems it doesn't work for preview channel. From v8 preview release metadata, there should be a runtime version of 8.0.0-preview.6.23329.7 but the associated base image tag is 8.0.0-preview.6. That's unfortunate because the ProcessFrameworkReferences actually does the all the job of processing version and outputs the RuntimeFramework item with Version property, and it already take care of SelfContained, TargetLatestRuntimePatch, RuntimeFrameworkVersion, etc,...

Maybe start from there and try to sanitize the value ?

[baronfel]

That's still a useful start - we can parse the FrameworkRuntimeVersion as a SemVer and only keep the first 'preview' segment + iteration. That's still a more useful/general rule than we're currently using, and we already have SemVer parsing in the _ComputeContainerBaseImageTag Task.

[richlander]

RuntimeFrameworkVersion is a (really) bad idea for this. Another (container-specific) property should be used.

Partial (but sufficient) context: https://github.com/dotnet/runtime/issues/90096

@elinor-fung

[baronfel]

Alright, we can back off of this approach then. The current approach will possibly float the user to a newer runtime than they may have manually specified (because we're using the major-minor version of the tag, but we generally try to be very compatible across those versions so it should be safe.

[richlander]

I have no issue with a ContainerPatchVersion tag (or similar). It's just that the use of RuntimeFrameworkVersion, which very much does other stuff (good and bad) in addition to it being useful for inference.

[scrocquesel]

Alright, we can back off of this approach then. The current approach will possibly float the user to a newer runtime than they may have manually specified (because we're using the major-minor version of the tag, but we generally try to be very compatible across those versions so it should be safe.

My use case is to be able to use Renovate to have a framework version that is manageable and predictable and being able to deduce the corresponding supported runtime image.

[scrocquesel]

RuntimeFrameworkVersion is a (really) bad idea for this. Another (container-specific) property should be used.

Partial (but sufficient) context: dotnet/runtime#90096

@elinor-fung

Does it means that we can actually build the application in an image with the same runtime version but it will not work ? I mean docker image are immutable, no one will ever install a newer version of the runtime afterward. It's not like running an application on host with a shared runtime installation that is update independently.

[richlander]

The issue is that RuntimeFrameworkVersion (as the linked issue suggests) only affects the base runtime and has no effect on other frameworks.

It's a supported feature, however, has very narrow utility, and we do not want to encourage its broad use (which this would do).