search

dotnet / dotnet-docker

Docker images for .NET and the .NET Tools.
https://hub.docker.com/_/microsoft-dotnet
MIT License
4.49k stars 1.94k forks source link

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

Open lbussell opened 1 year ago

lbussell commented 1 year ago

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: https://github.com/dotnet/dotnet-docker/issues/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 commented 1 year ago

You can see this today:

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

lbussell commented 1 year ago

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 commented 1 year ago

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 https://github.com/dotnet/dotnet-docker/issues/4343 and other linked issues/PRs for context). The incorrect testing infrastructure was hiding the fact that this problem still exists.

mthalman commented 1 year ago

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

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

mthalman commented 1 year ago

Never mind, you referenced it above: https://github.com/dotnet/dotnet-docker/issues/4827

mthalman commented 1 year ago

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

lbussell commented 1 year ago

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) - #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 - #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 https://github.com/dotnet/dotnet-docker/issues/4343 and other linked issues/PRs for context). The incorrect testing infrastructure [2] was hiding the fact that [3] is still a problem.

marinasundstrom commented 1 year ago

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.

lbussell commented 1 year ago

@marinasundstrom, that sounds like an unrelated issue. Please file a separate issue with repro steps and we'll be happy to help.

Just a reminder that .NET 8 RC1 isn't officially supported for production until it's released. mcr.microsoft.com/dotnet/nightly/sdk:8.0 currently contains a pre-release version of RC1, while mcr.microsoft.com/dotnet/sdk:8.0-preview contains the stable release of Preview 7.

gaiveknopf commented 1 year ago

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.

Hi Marina, did you manage to solve this problem? I've been trying for days but to no avail.