[release/7.0.1xx] Wrong version of aspnetcore.runtime.internal is pulled by GenerateLayout

[ayakael]

Wrong version of aspnetcore-runtime-internal-$(MicrosoftAspNetCoreAppRuntimePackageVersion)-$(AspNetCoreArchiveRid)$(ArchiveExtension) is pulled by installer when building source-build on Alpine Linux. Version 7.0.0-rc.1.22404 is expected, but aspnetcore builds 7.0.0-rc.2.22452.11. The following patch is used as workaround:

From db54f968bc5f0bcb327ca1e5362b314b3d952860 Mon Sep 17 00:00:00 2001
From: Antoine Martin <dev@ayakael.net
Date: Sun, 13 Feb 2022 21:59:46 +0000
Subject: [PATCH 2/2] 
 installer_forgotten-MicrosoftAspNetCoreAppRuntimePackageVersion-fix

 Somewhere along the way, installer forgets MicrosoftAspNetCoreApp-
 RuntimePackageVersion, thus expects version 6.0.0 when building 6.0.x.
 This reminds installer what version AspNetCoreappRuntime is by 
 re-setting it as what it is usually set.

---
 src/redist/targets/GenerateLayout.targets | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/installer/src/redist/targets/GenerateLayout.targets b/src/installer/src/redist/targets/GenerateLayout.targets
index e05004e17..d3573f401 100644
--- a/src/installer/src/redist/targets/GenerateLayout.targets
+++ b/src/installer/src/redist/targets/GenerateLayout.targets
@@ -96,6 +96,7 @@
       <DownloadedAspNetTargetingPackInstallerFileName Condition=" '$(InstallerExtension)' == '.msi' ">aspnetcore-targeting-pack-$(MicrosoftAspNetCoreAppRefInternalPackageVersion)-$(AspNetCoreInstallerRid)$(InstallerExtension)</DownloadedAspNetTargetingPackInstallerFileName>
       <DownloadedAspNetCoreV2ModuleInstallerFileName Condition=" '$(InstallerExtension)' == '.msi' ">aspnetcoremodule_$(Architecture)_en_v2_$(MicrosoftAspNetCoreAppRuntimePackageVersion)$(InstallerExtension)</DownloadedAspNetCoreV2ModuleInstallerFileName>
       <AspNetTargetingPackArchiveFileName>aspnetcore-targeting-pack-$(MicrosoftAspNetCoreAppRefPackageVersion)-$(AspNetCoreArchiveRid)$(ArchiveExtension)</AspNetTargetingPackArchiveFileName>
+      <MicrosoftAspNetCoreAppRuntimePackageVersion>$(MicrosoftAspNetCoreAppRuntimewinx64PackageVersion)</MicrosoftAspNetCoreAppRuntimePackageVersion>
       <AspNetCoreSharedFxArchiveFileName>aspnetcore-runtime-internal-$(MicrosoftAspNetCoreAppRuntimePackageVersion)-$(AspNetCoreArchiveRid)$(ArchiveExtension)</AspNetCoreSharedFxArchiveFileName>
 
       <!-- Used to detect if ASP.NET Core is built against the same version of Microsoft.NETCore.App. -->
-- 
2.35.1

This issue also affects .NET 6

[tmds]

MicrosoftAspNetCoreAppRuntimewinx64PackageVersion is the default value of MicrosoftAspNetCoreAppRuntimePackageVersion in eng/Versions.props.

MicrosoftAspNetCoreAppRuntimePackageVersion is changed by ExtraPackageVersionPropsPackageInfo to MicrosoftAspNetCoreAppRuntimeLinuxx64PackageVersion.

This causes a mismatch between the version produced by aspnetcore (MicrosoftAspNetCoreAppRuntimewinx64PackageVersion), and the version expected by installer (MicrosoftAspNetCoreAppRuntimeLinuxx64PackageVersion).

Either aspnetcore needs to change to build MicrosoftAspNetCoreAppRuntimeLinuxx64PackageVersion, or we should remove the ExtraPackageVersionPropsPackageInfo for MicrosoftAspNetCoreAppRuntimePackageVersion.

I don't know which one is the proper fix.

@crummel @MichaelSimons ptal.

[crummel]

I think we'll need to add a MUSL version of the runtime package here with the other alternative versions: https://github.com/dotnet/installer/blob/314db6c4f5199bad4bf06e2d826aded06e2b177b/src/SourceBuild/tarball/content/Directory.Build.props#L237. This seems to be the same issue we run into on Windows/Mac when we're not producing the linux-x64 runtime. Would you mind opening a PR for this?

[tmds]

In dotnet/installer#14549 I also run into this issue.

Can we use MicrosoftAspNetCoreAppRuntimewinx64PackageVersion (or something else) when we build aspnetcore, and then again when we consume it in installer, independent of the target platform?

[ayakael]

I think we'll need to add a MUSL version of the runtime package here with the other alternative versions:

https://github.com/dotnet/installer/blob/314db6c4f5199bad4bf06e2d826aded06e2b177b/src/SourceBuild/tarball/content/Directory.Build.props#L237

. This seems to be the same issue we run into on Windows/Mac when we're not producing the linux-x64 runtime. Would you mind opening a PR for this?

Do you mean we ought to do something like this:

diff --git a/eng/Versions.props b/eng/Versions.props
index 8f69d9cb0..279539a63 100644
--- a/eng/Versions.props
+++ b/eng/Versions.props
@@ -51,6 +51,7 @@
   <PropertyGroup>
     <!-- Dependencies from https://github.com/aspnet/AspNetCore -->
     <MicrosoftAspNetCoreAppRuntimewinx64PackageVersion>7.0.0-rc.2.22465.19</MicrosoftAspNetCoreAppRuntimewinx64PackageVersion>
+    <MicrosoftAspNetCoreAppRuntimemuslx64PackageVersion>$(MicrosoftAspNetCoreAppRuntimewinx64PackageVersion)</MicrosoftAspNetCoreAppRuntimewinx64PackageVersion>
     <MicrosoftAspNetCoreAppRefPackageVersion>7.0.0-rc.2.22465.19</MicrosoftAspNetCoreAppRefPackageVersion>
     <MicrosoftAspNetCoreAppRefInternalPackageVersion>7.0.0-rc.2.22465.19</MicrosoftAspNetCoreAppRefInternalPackageVersion>
     <VSRedistCommonAspNetCoreSharedFrameworkx6470PackageVersion>7.0.0-rc.2.22465.19</VSRedistCommonAspNetCoreSharedFrameworkx6470PackageVersion>
diff --git a/src/SourceBuild/tarball/content/Directory.Build.props b/src/SourceBuild/tarball/content/Directory.Build.props
index 797e54fa6..2daf16661 100644
--- a/src/SourceBuild/tarball/content/Directory.Build.props
+++ b/src/SourceBuild/tarball/content/Directory.Build.props
@@ -236,6 +236,7 @@
     <!-- OSX needs the OSX version instead of Linux.  We don't have a lot of flexibility in how we output these properties so we're relying on the previous one being blank if the Linux vers
ion of the package is missing.  -->
     <ExtraPackageVersionPropsPackageInfo Include="MicrosoftAspNetCoreAppRuntimePackageVersion" Version="%24(MicrosoftAspNetCoreAppRuntimeOsxX64PackageVersion)" DoNotOverwrite="true" />
     <ExtraPackageVersionPropsPackageInfo Include="MicrosoftAspNetCoreAppRuntimePackageVersion" Version="%24(MicrosoftAspNetCoreAppRuntimewinx64PackageVersion)" DoNotOverwrite="true" />
+    <ExtraPackageVersionPropsPackageInfo Include="MicrosoftAspNetCoreAppRuntimePackageVersion" Version="%24(MicrosoftAspNetCoreAppRuntimemuslx64PackageVersion)" DoNotOverwrite="true" />
 
     <!-- Used by installer to determine sdk version -->
     <ExtraPackageVersionPropsPackageInfo Include="MicrosoftDotnetToolsetInternalPackageVersion" Version="%24(MicrosoftNETSdkPackageVersion)" />

[tmds]

Do you mean we ought to do something like this:

Any fix that doesn't cause aspnetcore and installer to read the version from the same source is a bad one imo.

[ayakael]

Do you mean we ought to do something like this:

Any fix that doesn't cause aspnetcore and installer to read the version from the same source is a bad one imo.

I'm a bit out of my depth so I can refer to ya'll for proper implementation.

[tmds]

I mean that the source tarball should pass the version number to build to aspnetcore and then use that same version number when installer gets the artifacts.

@crummel is that possible?

I don't understand how the tarball tells aspnetcore what version it should build.

Is this done using?

https://github.com/dotnet/installer/blob/429fe082c9fa5d67efc070f669f24bac6f48fc6a/src/SourceBuild/tarball/content/Directory.Build.props#L223-L224

[ayakael]

Given @tmds already exploring a fix in dotnet/installer#14549, I am closing my own PR.

[tmds]

Based on how this behaves, it seems aspnetcore picks up one of these MicrosoftAspNetCoreAppRuntimeXXXPackageVersion if XXX is the platform being built. It's a mystery to me how this happens.
If that property is missing, it falls back to the MicrosoftAspNetCoreAppRuntimewinx64PackageVersion which gets set to aspnetcoreOutputPackageVersion by ExtraPackageVersionPropsPackageInfo.

Then the logic for ExtraPackageVersionPropsPackageInfo tries to set MicrosoftAspNetCoreAppRuntimePackageVersion to the version that was built based on what MicrosoftAspNetCoreAppRuntimeXXXPackageVersion are set. That is the version consumed by installer.

I think it would be best if we can make aspnetcore always produce aspnetcoreOutputPackageVersion, and installer always consume aspnetcoreOutputPackageVersion. Then there is no possible mismatch.

I don't know how to do this because I don't know what the proper way is to tell aspnetcore it should always build aspnetcoreOutputPackageVersion even in the presence of MicrosoftAspNetCoreAppRuntimeXXXPackageVersion properties.