Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings

Directory for $PSHome when updating on Windows with MSI #5226

Copy link
Copy link
@joeyaiello

Description

@joeyaiello
Issue body actions

On Windows, when we do an update install with an MSI, the directory of $PSHome gets changed to reflect the version number. For example, C:\Program Files\PowerShell\6.0.0-beta.8 gets changed to C:\Program Files\PowerShell\6.0.0-beta.9.

Unfortunately, this breaks any user-created shortcuts that are hard-coded to the exact path of PowerShell. Similarly, apps like VS Code get hardcoded to that path and will break after an update install.

AFAICT, there's a couple of paths forward here:

  1. It might not matter at all once we move to pwsh and add $PSHome to the PATH. Anyone who wants stability should build their shortcuts, VS Code preferences, and shell/batch scripts against pwsh and not the full path.
  2. We change behavior to only use the major and minor versions (e.g. 6.0 and 6.1and not the revision number). That way, when we update to 6.1 we can keep them side-by-side. However, that might not be desirable if we maintain strict semantic versioning (i.e. don't make breaking changes between minor versions).
  3. We change behavior to only use the major version (e.g. 6). This is similar to the Office or VS Code approach (e.g. Office12 vs. Office13). This may be overoptimizing if we never do a PowerShell 7, or it might be the right solution if we maintain strict semantic versioning.

My main goal here is not to over-optimize for an uncertain future. That's why I'm leaning towards 1, but I want to get people's thoughts.

Reactions are currently unavailable

Metadata

Metadata

Assignees

No one assigned

    Labels

    Issue-Discussionthe issue may not have a clear classification yet. The issue may generate an RFC or may be reclassifthe issue may not have a clear classification yet. The issue may generate an RFC or may be reclassifOS-WindowsResolution-FixedThe issue is fixed.The issue is fixed.

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

      Morty Proxy This is a proxified and sanitized view of the page, visit original site.