Powershell: Installing PowerShell 7.0.0 GA removed my PS 6 install

Created on 4 Mar 2020  路  24Comments  路  Source: PowerShell/PowerShell

After installing the 7.0.0 GA, I discovered that my PS 6.2 folder was empty. Is this intended?

I Installed using PowerShell-7.0.0-win-x64.msi

Expected behavior

I expected that my PowerShell 6 release would have been left in place.

Actual behavior

C:Program FilesPowerShell6 is empty.
Any shortcuts or tasks targeting that release are not broken.

Environment data

Name                           Value
----                           -----
PSVersion                      7.0.0
PSEdition                      Core
GitCommitId                    7.0.0
OS                             Microsoft Windows 10.0.18363
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0鈥
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0
Issue-Question

Most helpful comment

I am fine with the $env:path getting cleared so you only get the latest when you run pwsh. But I don't think it should remove the 6 files. Any place we have a full path specified will be broken.

This makes the install of 7 over 6 a dangerous upgrade that can break things even if it would have been compatible. We have been preaching the side by side nature of PowerShell to the community for a while now and deleting those files breaks that promise.

All 24 comments

Seconding this, I was rather surprised when my PowerShell 6 install was removed.

Same here. Hmm...

I lost everything in /Program Files/PowerShell/6, 6.0.4, and 6-preview. Launching PowerShell 6.2.4 in the Windows Terminal resulted in "[error 0x80070002 when launching 'C:\Program Files\PowerShell\6\pwsh.exe'].

For anyone who comes across this, you can keep your 6 install side-by-side by just copying the PowerShell6 folder somewhere else prior to installing 7. Doesn't help if you've already lost your 6 install though :(.

Same. While excited for 7 we will have use for PowerShell 6 for some time. Wasn't expecting it to be removed.

Checking on this

It was discussed long time ago and it is by design because we can have only single "main" version.

Not sure that makes sense. What is the point then of installing into versioned directories: 6 and 7?

It's fine for there to only be one 'main' version advertised by GitHub or by installation scripts, but we still have a use for 6, why does it need to remove 6 on my local system when they run fine as separate executables?

why does it need to remove 6 on my local system when they run fine as separate executables?

_Because it is design for MSI installer. If you want install 7.0 as SxS you must use ZIP package._

I won鈥檛 be surprised if this is in the documentation.

Looks like I missed some team discussion on this or forgot about it. Anyways, the official answer is that PS7 is expected to be an update over PS6. So the current behavior is by-design. We'll make sure docs call it out explicitly.

I am fine with the $env:path getting cleared so you only get the latest when you run pwsh. But I don't think it should remove the 6 files. Any place we have a full path specified will be broken.

This makes the install of 7 over 6 a dangerous upgrade that can break things even if it would have been compatible. We have been preaching the side by side nature of PowerShell to the community for a while now and deleting those files breaks that promise.

Because it is design for MSI installer. If you want install 7.0 as SxS you must use ZIP package.

The MSI could have been designed with SxS as an option. Or it could have warned that it was going to remove 6.x versions.

Please see PowerShell Committee conclution https://github.com/PowerShell/PowerShell-RFC/pull/202#issuecomment-516135008

I understand the reasoning, but at the end of the day this is a behavior change from previous updates. It doesn't even particularly matter to me where this ends up, other SxS installation methods are available. But there was no communication on this and there's nothing I can find in the docs. This should be communicated in the main README file on the github page imo.

Yeah communication should have been significantly more overt and clear here. I don't think we can reasonably expect an appreciable percentage of pwsh users to be regularly checking / taking notes on occurrences in the RFC repo.

If a change in behaviour or policy is documented in a way that changes something significantly, it probably should be documented outside the repo in a help topic, and probably publicised by the powershell team.

Worth noting that on macOS and Linux, upgrading PowerShell through the package manager necessarily clobbers the previous install. So far all the stable installs have removed the previous one on all platforms.

The MSI could have been designed with SxS as an option.

This will lead to bugs. PowerShell depends on some environment variables, which constantly leads to problems of coexistence, but the MSFT team is not yet ready to abandon these dependencies.

Worth noting that on macOS and Linux, upgrading PowerShell through the package manager necessarily clobbers the previous install.

And having the same experience on all platforms is very good UX.

This makes the install of 7 over 6 a dangerous upgrade that can break things even if it would have been compatible. We have been preaching the side by side nature of PowerShell to the community for a while now and deleting those files breaks that promise.

From a code perspective, it's no more dangerous than us doing an in-place upgrade from 6.0 to 6.1 and then again to 6.2 (which we did do). The trade off here was against having a dangling 6.2 on your box that's out of support in <6 months and can't be upgraded to a supported, serviceable state.

I hear everyone that we could have communicated better, and I can add some of this language to my announcement blog if folks think it would be helpful as a call out there.

The trade off here was against having a dangling 6.2 on your box that's out of support in <6 months and can't be upgraded to a supported, serviceable state.

FWIW this happened to me. Had 6.0.2 on my box and didn't realise for a year until I picked it up as a bug when writing this.

Perhaps an MSI installer flag should be added that allows the customer to "KeepExistingPwshVersions"?
Then customers can decide at install time whether they want previous versions removed or not.

Will PowerShell 8 automatically remove 7 when that is released or will 7 not be touched because it is a long term support release?

For next version numbering #12057

Was this page helpful?
0 / 5 - 0 ratings