Skip to content

Fix logic for .msi version in Hosting Bundle #62147

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

Merged
merged 1 commit into from
May 28, 2025
Merged

Fix logic for .msi version in Hosting Bundle #62147

merged 1 commit into from
May 28, 2025

Conversation

wtgodbe
Copy link
Member

@wtgodbe wtgodbe commented May 28, 2025

The aspnetcore-runtime .msi will have a stable version in servicing, but we always need to calculate the non-stable version for when we restore assets in VMR build pass 2. Fixes #61951

@wtgodbe wtgodbe requested a review from a team as a code owner May 28, 2025 20:07
@github-actions github-actions bot added the needs-area-label Used by the dotnet-issue-labeler to label those issues which couldn't be triaged automatically label May 28, 2025
@wtgodbe wtgodbe requested a review from Copilot May 28, 2025 20:12
Copy link
Contributor

@Copilot Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull Request Overview

This PR refactors how the MSI version is computed for the hosting bundle by introducing a dedicated NonStableVersion property and updating the installer path normalization to use it.

  • Introduce NonStableVersion MSBuild property with conditional logic to append prerelease/build labels.
  • Update CrossArchitectureInstallerBasePathNormalized to reference NonStableVersion instead of SharedFxMsiVersion.
Comments suppressed due to low confidence (2)

src/Installers/Windows/WindowsHostingBundle/WindowsHostingBundle.wixproj:107

  • The condition checks for the absence of $(_BuildNumberLabels) instead of $(_PreReleaseLabel). If the intention is to append labels only when there is no prerelease label, the condition should verify ! $(NonStableVersion.Contains('$(_PreReleaseLabel)')) instead.
<NonStableVersion Condition="! $(NonStableVersion.Contains('$(_BuildNumberLabels)'))">$(PackageVersion)-$(_PreReleaseLabel)$(_BuildNumberLabels)</NonStableVersion>

src/Installers/Windows/WindowsHostingBundle/WindowsHostingBundle.wixproj:105

  • [nitpick] Consider adding an MSBuild integration test or target that verifies NonStableVersion yields the correct values for both stable and prerelease scenarios to prevent regressions.
<NonStableVersion>$(PackageVersion)</NonStableVersion>

@wtgodbe wtgodbe added area-infrastructure Includes: MSBuild projects/targets, build scripts, CI, Installers and shared framework and removed needs-area-label Used by the dotnet-issue-labeler to label those issues which couldn't be triaged automatically labels May 28, 2025
@wtgodbe wtgodbe merged commit 5e56818 into main May 28, 2025
28 checks passed
@wtgodbe wtgodbe deleted the wtgodbe/HostBund branch May 28, 2025 22:12
@dotnet-policy-service dotnet-policy-service bot added this to the 10.0-preview6 milestone May 28, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-infrastructure Includes: MSBuild projects/targets, build scripts, CI, Installers and shared framework
Projects
None yet
Development

Successfully merging this pull request may close these issues.

ASPNetCore produces a stable-branded .msi for targeting packs and runtimes
2 participants