Powershell: Can't install 32-bit/64-bit PowerShell together when using MSI installer

Created on 1 Dec 2017  路  8Comments  路  Source: PowerShell/PowerShell

Steps to reproduce

I installed 64-bit PowerShell 6.0-rc using MSI installer first.
Next I installed 32-bit PowerShell 6.0-rc using MSI installer.

Expected behavior

Both 64-bit and 32-bit PowerShell is installed.

Actual behavior

64-bit PowerShell was removed.

Environment data

  • 64-bit Windows 10 Pro(1703)
> $PSVersionTable
Name                           Value
----                           -----
PSVersion                      6.0.0-rc.2
PSEdition                      Core
GitCommitId                    v6.0.0-rc.2
OS                             Microsoft Windows 10.0.15063
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0
Area-Maintainers-Build Issue-Question Resolution-Fixed

All 8 comments

@stknohg Thanks for reporting this severe bug. Could you also please state if you reported this bug just because you found it or if you have a use case where you need to have 32 and 64 bit installed? This would help estimate the customer impact of it.
About the bug:
I think the -arch x64 argument to candle.exe here is the culprit since it apparently overrides the Platform originally defined by ProductTargetArchitecture. Therefore WiX wrongly thinks that the 32 bit installer is 64 bit. Addiitionally, I found that another problem is the UpgradeCode, which is hardcoded. With those 2 fixes, side by side works. I will prepare a PR with a fix for it.

Yes, Thanks for reporting this bug.

@TravisEz13 @SteveL-MSFT I think we can close the issue now with the PR being merged into master and the release branch.

@bergmeister in the future, you can have issues auto-close on merge with special key words: https://help.github.com/articles/closing-issues-using-keywords/

Thanks, I did not know that. But it also sounds dangerous because it should be a conscious decision and review of maintainers. What if the PR says 'partially fixes '? GitHub would close the issue then. VSTS has a checkbox to close related task that can be ticked upon completion of a PR.

@bergmeister It is something the PR assignee is responsible for checking before merging. Collaborators/maintainers/owners can update the PR details if needed before merging or they can re-open the issue. Issue watchers also get notified on close and can always request it be re-opened. I'd say the risk is low.

馃槃 There was an extra word in "Fix bug #5597"

I confirmed that the problem was solved.
Thank you everyone.

Was this page helpful?
0 / 5 - 0 ratings