Skip to content

[release/3.1] Make sure SharedFx & TargetingPack msi names match #30439

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.

Sign up for GitHub

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

Jump to bottom
Merged
merged 2 commits into from
Mar 9, 2021
Merged

[release/3.1] Make sure SharedFx & TargetingPack msi names match #30439

merged 2 commits into from
Mar 9, 2021

Conversation

wtgodbe
Copy link
Member

@wtgodbe wtgodbe commented Feb 24, 2021 •
edited
Loading

3.1 port of #28298 and #28572. Should fix customer reports of being unable to upgrade/repair 3.1 Asp.Net bits via the .msi's. More context in #28029

The name of the standalone .msi's here weren't matching what gets into VS, meaning that you can't repair a VS installation with the standalone bundle. The solution is to make sure the names match in both places (the .msi should be versioned)

@wtgodbe
Make sure SharedFx & TargetingPack msi names match (#28298)
413ea05 
* Make sure SharedFx & TargetingPack msi names match

* Insert packageVersion into OutputName when available

* Move props around again
@wtgodbe
Fix .msi names (#28572)
30e5d11
@wtgodbe wtgodbe requested review from joeloff and a team February 24, 2021 20:37
@ghost ghost added the area-infrastructure Includes: MSBuild projects/targets, build scripts, CI, Installers and shared framework label Feb 24, 2021
@wtgodbe
Copy link
Member Author

wtgodbe commented Feb 24, 2021

Internal build to grab .msi/.exe's: https://dnceng.visualstudio.com/internal/_build/results?buildId=1010396&view=results

@wtgodbe wtgodbe changed the title Wtgodbe/31msi backport [release/3.1] Make sure SharedFx & TargetingPack msi names match Feb 24, 2021
dougbu
dougbu approved these changes Feb 24, 2021
View reviewed changes
Copy link
Contributor

@dougbu dougbu left a comment

Choose a reason for hiding this comment

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

This will require an upstream reaction, correct❔

@wtgodbe
Copy link
Member Author

wtgodbe commented Feb 24, 2021

This will require an upstream reaction, correct❔

It shouldn't, dotnet/installer is already grabbing the nonstable .msi: https://github.com/dotnet/installer/blob/f630cdf91d154d913af945714dfdd2b414586308/src/redist/targets/GenerateLayout.targets#L80. This doesn't change the name of the .msi we publish, it just stops it from being renamed when it's brought into the shared WixLib.

@wtgodbe
Copy link
Member Author

wtgodbe commented Feb 24, 2021 •
edited
Loading

I checked out out an installer produced by this build and confirmed that the .exe now references the .msi by its actual name rather than by AspNetCoreSharedFramework-x64.msi

@wtgodbe wtgodbe added the tell-mode Indicates a PR which is being merged during tell-mode label Feb 25, 2021
@wtgodbe wtgodbe added this to the 3.1.14 milestone Feb 25, 2021
@danmoseley danmoseley mentioned this pull request Feb 26, 2021
Closed
@wtgodbe wtgodbe merged commit b8a46a8 into release/3.1 Mar 9, 2021
@wtgodbe wtgodbe deleted the wtgodbe/31MSIBackport branch March 9, 2021 22:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@dougbu dougbu dougbu approved these changes

@joeloff joeloff joeloff approved these changes

Assignees
No one assigned
Labels
area-infrastructure Includes: MSBuild projects/targets, build scripts, CI, Installers and shared framework tell-mode Indicates a PR which is being merged during tell-mode
Projects
None yet
Milestone
3.1.14
Development

Successfully merging this pull request may close these issues.
3 participants
@wtgodbe @dougbu @joeloff