ASP.NET Composite runtime and non-composite .NET runtime versions are out of sync for some preview versions

[lbussell]

This is because the version of the composite runtime and the normal runtime are built from different locations. During preview dependency flows, the versions can get out of sync until the product is locked down for the next preview.

You can see this today:

> docker pull mcr.microsoft.com/dotnet/nightly/aspnet:8.0-alpine3.18-composite-amd64
digest: sha256:6a39b9c4d3e9e0c24ebb6432ff90e81f00b011ac6683f946eae78c179440eb71

> docker run --rm --entrypoint "/bin/sh" mcr.microsoft.com/dotnet/nightly/aspnet:8.0-alpine3.18-composite-amd64 -c 'echo $DOTNET_VERSION'
8.0.0-rc.1.23414.4

> docker run --rm --entrypoint "/bin/sh" mcr.microsoft.com/dotnet/nightly/aspnet:8.0-alpine3.18-composite-amd64 -c 'dotnet --list-runtimes | grep "Microsoft.NETCore.App"'
Microsoft.NETCore.App 8.0.0-rc.1.23414.1 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

The current test infrastructure has bugs for composite images that don't correctly test this environment variable: #4827

When this is fixed the test will always fail when this variable is incoherent between the runtime and aspnet composite runtime images. Ideally we would compute the correct DOTNET_VERSION environment variable to use for the composite images, so that even if they're different between different image versions, the environment variable correctly describes which runtime version is in the Docker image.

[richlander]

You can see this today:

The problem isn't obvious to me. Can you elaborate?

[lbussell]

Our DOTNET_VERSION environment variable says that we have .NET Runtime version 8.0.0-rc.1.23414.4 but the version actually in the container is 8.0.0-rc.1.23414.1.

[lbussell]

This issue also causes apps built on preview SDKs to be unable to run on composite images, with the following error:

You must install or update .NET to run this application.

App: /app/app.dll
Architecture: x64
Framework: 'Microsoft.NETCore.App', version '8.0.0-rc.1.23414.4' (x64)
.NET location: /usr/share/dotnet/

The following frameworks were found:
  8.0.0-rc.1.23414.1 at [/usr/share/dotnet/shared/Microsoft.NETCore.App]

Learn more:
https://aka.ms/dotnet/app-launch-failed

To install missing framework, download:
https://aka.ms/dotnet-core-applaunch?framework=Microsoft.NETCore.App&framework_version=8.0.0-rc.1.23414.4&arch=x64&rid=linux-musl-x64&os=alpine.3.18

This issue was discussed at length during design meetings for the composite runtime images (dig through #4343 and other linked issues/PRs for context). The incorrect testing infrastructure was hiding the fact that this problem still exists.

[mthalman]

The incorrect testing infrastructure was hiding the fact that this problem still exists.

What's incorrect here? Is this a separate issue?

[mthalman]

Never mind, you referenced it above: #4827

[mthalman]

So it seems that issue should be updated because it's not specific to "locally" run tests, is that correct?

[lbussell]

Sorry, I could have made this clearer. There are 3 issues at hand.

1. ASP.NET composite tests fail without a correct image-info.json (which is what happens when you run tests locally) - Tests fail to run correctly outside of CI (without an image-info.json) #4827
2. ASP.NET composite tests are incorrect or fail to test the correct composite images. This is how we see this issue (4834) manifest while the composite images continue to pass tests - This is unrelated to 4827 and does not have an issue filed.
3. ASP.NET composite images contain a runtime version that's incoherent with the SDK image - ASP.NET Composite runtime and non-composite .NET runtime versions are out of sync for some preview versions #4834

I am working on a PR that addresses [1] and [2] and temporarily disables scenarios that fail because of [3].

Amending my previous statement,

This issue [3] was discussed at length during design meetings for the composite runtime images (dig through #4343 and other linked issues/PRs for context). The incorrect testing infrastructure [2] was hiding the fact that [3] is still a problem.

[marinasundstrom]

I have a project that I upgraded my app to target .NET 8 RC1. It has not worked.
The app builds and run locally, but not in Docker using the preview tag. The build fails due to not resolving calls.

So the SDKs are not in sync.

A funny detail is that there is no daily build named RC1. The SDK is tagged RC2 but contains a RC1 build.

Anyway, I can't build and deploy my apps until that is solved.