Skip to content

Enable install of Preview MSI release side-by-side with Stable release#8513

Merged
TravisEz13 merged 2 commits intoPowerShell:masterfrom
SteveL-MSFT:msi-preview
Jan 2, 2019
Merged

Enable install of Preview MSI release side-by-side with Stable release#8513
TravisEz13 merged 2 commits intoPowerShell:masterfrom
SteveL-MSFT:msi-preview

Conversation

@SteveL-MSFT
Copy link
Member

@SteveL-MSFT SteveL-MSFT commented Dec 21, 2018

PR Summary

When installing (or upgrading) Preview builds the component ids for the files are the same as the installed files from the stable MSI. MSI sees this and assumes the file is already installed so skips installing files that haven't changed (been updated) which results in missing files in the preview install folder and pwsh fails to start. Fix is to dynamically generate new component ids (and compoentrefs) in files.wxs using _Preview suffix and use that when building a preview package.

Tested manually.

cc @bergmeister if you can help validate different scenarios.

Fix #8289

PR Checklist

generate unique component ids for preview release
@iSazonov iSazonov added the CL-BuildPackaging Indicates that a PR should be marked as a build or packaging change in the Change Log label Dec 21, 2018
Copy link
Contributor

@PaulHigin PaulHigin left a comment

Choose a reason for hiding this comment

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

LGTM

Copy link
Contributor

@bergmeister bergmeister left a comment

Choose a reason for hiding this comment

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

Interesting approach, at first it seems to be the right approach but then I was thinking to myself:
What if we just used "*" (meaning: auto-generate random GUID) for the Component GUIDs in Files.wxs, would that not achieve the same without needing to write code?
In general: what about applying something similar to Product.wxs as well whatever the best approach turns out to be?

@SteveL-MSFT
Copy link
Member Author

SteveL-MSFT commented Dec 22, 2018

@bergmeister If I'm understanding the docs correctly:

Component identifier; this is the primary key for identifying components. If omitted, the compiler defaults the identifier to the identifier of the resource that is the explicit keypath of the component (for example, a child File element with KeyPath attribute with value 'yes'.

The generated id is the keypath of the file, example

      <Component Id="cmpE67BDD4BD52046578E30F0B2181877BA" Guid="{E67BDD4B-D520-4657-8E30-F0B2181877BA}">
        <File Id="filE67BDD4BD52046578E30F0B2181877BA" KeyPath="yes" Source="$(env.ProductSourcePath)\System.DirectoryServices.dll" />
      </Component>

$env:ProductSourcePath is the source of the built binaries, not the destination. So it'd be exactly the same for stable and preview builds. product.wxs just consumes files.wxs during the packaging process.

address Chris' feedback
cleanup temp files-preview.wxs
@bergmeister
Copy link
Contributor

bergmeister commented Dec 31, 2018

Thanks Steve for clarification and cleaning up the temporary file. I noticed that the deletion of temporary files does not happen using a try-finally pattern in this function but I think for the purpose of this function that does not get called too often, it's probably good enough for that.
Looks good to me otherwise.

@TravisEz13 TravisEz13 merged commit 725bfda into PowerShell:master Jan 2, 2019
@SteveL-MSFT SteveL-MSFT deleted the msi-preview branch January 4, 2019 09:13
TravisEz13 added a commit to TravisEz13/PowerShell that referenced this pull request Feb 28, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

CL-BuildPackaging Indicates that a PR should be marked as a build or packaging change in the Change Log

Projects

None yet

Development

Successfully merging this pull request may close these issues.

PowerShell-6.2.0-preview.2-win-x64 error on startup (also occurs on upgrade to preview.3)

5 participants