Skip to content

Conversation

@wtgodbe
Copy link
Member

@wtgodbe wtgodbe commented Dec 1, 2020

Resolves #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 wtgodbe added the tell-mode Indicates a PR which is being merged during tell-mode label Dec 1, 2020
@wtgodbe wtgodbe added this to the 5.0.2 milestone Dec 1, 2020
@wtgodbe wtgodbe requested review from a team and joeloff December 1, 2020 23:02
@ghost ghost added the feature-installers Includes: Installers label Dec 1, 2020
@joeloff
Copy link
Member

joeloff commented Dec 1, 2020

Check the wixlib authoring. I seem to remember it referencing the MSI name using the project reference, but I'm almost certain it's using the project.outputname, so we should be good then.

Copy link
Member

@joeloff joeloff left a comment

Choose a reason for hiding this comment

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

Looks good, but we just need to confirm the wixlib reference

@wtgodbe wtgodbe force-pushed the wtgodbe/SharedFxName branch from 7def3b8 to e1e676b Compare December 2, 2020 22:12
@wtgodbe
Copy link
Member Author

wtgodbe commented Dec 2, 2020

@JunTaoLuo @joeloff please re-review - the previous issue was that OutputName needs to be set in the .wixproj's before they import d.b.t, but packageVersion isn't available until after we import d.b.t. So, I set a prefix and suffix to outputname in the projects, then construct it from those + the packageVersion in wix.common.targets, where packageversion is available.

@joeloff
Copy link
Member

joeloff commented Dec 2, 2020

And PackageName should remain consistent when it's doing the copy/rename later on? Or is that a potential issue to deal with in the future if something gets renamed?

@wtgodbe
Copy link
Member Author

wtgodbe commented Dec 2, 2020

And PackageName should remain consistent when it's doing the copy/rename later on? Or is that a potential issue to deal with in the future if something gets renamed?

Do you mean PackageFileName? I'm not exactly sure what the copy/rename behavior is - but, this maintains the old scheme (OutputName is set before we import the props/targets from WiX, PackageFileName is set after we're done processing Directory.Build.Targets and the WiX targets), I just had to move the setting of OutputName to after PackageVersion is available. I believe the timing should be the same as before, just with different names.

@joeloff
Copy link
Member

joeloff commented Dec 2, 2020

Ok, as long as the target runs for each project separately, then

<Target Name="CopyToArtifactsDirectory"
should be using the same value and then we're good

@wtgodbe
Copy link
Member Author

wtgodbe commented Dec 3, 2020

The .msi is now named aspnetcore-runtime-5.0.1-ci-win-x64.msi (plus the same for x86, arm64)

@wtgodbe wtgodbe merged commit a4f30ae into release/5.0 Dec 8, 2020
@wtgodbe wtgodbe deleted the wtgodbe/SharedFxName branch December 8, 2020 22:14
wtgodbe added a commit that referenced this pull request Feb 24, 2021
* Make sure SharedFx & TargetingPack msi names match

* Insert packageVersion into OutputName when available

* Move props around again
wtgodbe added a commit that referenced this pull request Mar 9, 2021
)

* Make sure SharedFx & TargetingPack msi names match (#28298)

* Make sure SharedFx & TargetingPack msi names match

* Insert packageVersion into OutputName when available

* Move props around again

* Fix .msi names (#28572)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

feature-installers Includes: Installers tell-mode Indicates a PR which is being merged during tell-mode

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants