-
Notifications
You must be signed in to change notification settings - Fork 132
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[release/7.0.1xx] Wrong version of aspnetcore.runtime.internal is pulled by GenerateLayout #3121
Comments
This causes a mismatch between the version produced by Either I don't know which one is the proper fix. @crummel @MichaelSimons ptal. |
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? |
In dotnet/installer#14549 I also run into this issue. Can we use |
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)" /> |
Any fix that doesn't cause |
I'm a bit out of my depth so I can refer to ya'll for proper implementation. |
I mean that the source tarball should pass the version number to build to @crummel is that possible? I don't understand how the tarball tells Is this done using? |
Given @tmds already exploring a fix in dotnet/installer#14549, I am closing my own PR. |
Based on how this behaves, it seems Then the logic for I think it would be best if we can make I don't know how to do this because I don't know what the proper way is to tell |
I agree, code that's magic is bad code. Those logics shouldn't be so opaque. When does this version have to be any other than |
What I have in dotnet/installer#14549 renames Maybe the fix is to remove @crummel wdyt? |
Yes, I think what has changed here is that once upon a time ASP.NET produced and installer consumed some unstable-versioned packages and some stable-version packages.
It now appears both the |
Another way to test this would be to pull the changes into @omajid's PR to add an Alpine CI leg - dotnet/installer#14417. The PR hit this issue. |
Of note, @tmds fix, that is to say changing the name of |
That's fine as a patch in the packages. I renamed the property to stop it from being overridden. The proper fix is to stop overriding it, which is what @crummel was doing in dotnet/installer#14769. We should take another look at that and figure out why it didn't work. I think it may be because pre-PR installer stuff gets used which causes the version still to be overridden. |
When I extract So we need to remove all We can rename the property as my patch did, and what is included in dotnet/installer#14816. And once artifacts tar.gz files no longer include @crummel @MichaelSimons how does that sound to you? |
dotnet/installer#14938 implements it. It combines my patch with @crummel's PR. |
Wrong version of
aspnetcore-runtime-internal-$(MicrosoftAspNetCoreAppRuntimePackageVersion)-$(AspNetCoreArchiveRid)$(ArchiveExtension)
is pulled by installer when building source-build on Alpine Linux. Version7.0.0-rc.1.22404
is expected, but aspnetcore builds7.0.0-rc.2.22452.11
. The following patch is used as workaround:This issue also affects .NET 6
The text was updated successfully, but these errors were encountered: