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

[najeebanwer]

Steps to reproduce

pwsh-preview

Expected behavior

Launch PowerShell-6.2.0-preview.2

Actual behavior

Gives the following error:

Error:
An assembly specified in the application dependencies manifest (pwsh.deps.json) was not found:
package: 'System.Private.ServiceModel', version: '4.5.3'
path: 'runtimes/win/lib/netstandard2.0/System.Private.ServiceModel.dll'

Environment data

> $PSVersionTable

N/A

[kborowinski]

Workaround:
Run the installer again and use repair function. It will fix the problem.

[najeebanwer]

@kborowinski:
Yes, that works. Thanks.
However, it should work after the initial installation and not require a repair.

[DarwinJS]

I am having the same problem after an upgrade using the chocolatey package I created for preview. I will avoid updating the chocolatey.org repo until this is fixed so that I don't get lotsa complaints ;)

[bergmeister]

This seems to be an upgrade problem only (I could reproduce when upgrading from 6.2-preview1 to 6.2-preview1). Uninstalling and reinstalling is fine and fixes it

[Agazoth]

I had the same issue upgrading using the msi file on W10.

[iSazonov]

/cc @SteveL-MSFT

[SteveL-MSFT]

Will investigate next week

[damianog]

Same issue to me from 6.2-preview1 to 6.2-preview2 msi installation

[SteveL-MSFT]

Preview.3 is coming out next week, so will wait to see if this repros.

[DarwinJS]

It is sort of reproing - though I am going over 6.2 preview 3 and it is a different error:

And as with preview 2, uninstall and reinstall works fine.

[MaximoTrinidad]

Can someone post which build of Windows 10 got the PowerShell Core error??

:)

[DarwinJS]

10.0.17134

[MaximoTrinidad]

Never mind finding the build number for Windows 10!

I just checked that when upgrading from Preview 2 to Preview 3, PowerShell Core won't start.

The installation completes without any failure but either click on the preview icon, or executing from the home folder won't work.

Microsoft Windows [Version 10.0.18282.1000]
(c) 2018 Microsoft Corporation. All rights reserved.

C:\Users\max_t>cd C:\Program Files\PowerShell\6-preview

C:\Program Files\PowerShell\6-preview>pwsh
Error:
  An assembly specified in the application dependencies manifest (pwsh.deps.json) was not found:
    package: 'System.ServiceModel.Duplex', version: '4.5.3'
    path: 'lib/netstandard2.0/System.ServiceModel.Duplex.dll'

C:\Program Files\PowerShell\6-preview>ver

Microsoft Windows [Version 10.0.18282.1000]

C:\Program Files\PowerShell\6-preview>

Workaround to this issue is to uninstall the previous version before installing Preview-3.
:)

[bergmeister]

I can confirm this happens not only when upgrading 6.2-preview1 to 6.2-preview3 but also when upgrading 6.2-preview2 to 6.2-preview3

[DarwinJS]

In my case it happened when upgrading from 6.2-preview2 that had been upgraded from 6.2-preview1. I would have to test a 6.2-preview1 to 6.2-preview3 upgrade to know if that scenario also generates an error.

[MaximoTrinidad]

@DarwinJS

I have confirmed upgrading from Preview.1 to Preview.3, installation complete without any failures but still PowerShell Core won't start.

:)

[MaximoTrinidad]

@DarwinJS

Ah! Just another FYI

Instead of uninstall, you click Repair, it will fix the issue too.

:)

[SteveL-MSFT]

I believe we've found the root cause. Since we have both stable and preview releases, we've been using the same componentid's for the same set of files. MSI is trying to be "smart" where if a previously registered component (aka file) is already installed (like you have 6.1.1 installed with same file), then it won't install it again. So that file is missing from 6.2-preview which causes it to fail to start. Proposed fix is to generate new componentids for the preview releases so they don't match any of the stable files. cc @TravisEz13

Example from msi log

MSI (s) (D8:1C) [13:08:12:977]: Disallowing installation of component: {A60E946A-2C86-4104-B883-D4B17B50B5B0} since the same component with higher versioned keyfile exists
MSI (s) (D8:1C) [13:08:13:165]: Disallowing installation of component: {7E693303-C675-4985-A1F0-84688E685656} since the same component with higher versioned keyfile exists
MSI (s) (D8:1C) [13:08:13:274]: Disallowing installation of component: {7E58EF48-5AD3-4889-8643-02CAC6C8EBAD} since the same component with higher versioned keyfile exists
MSI (s) (D8:1C) [13:08:13:412]: Disallowing installation of component: {C119D8F5-B184-44F4-9765-CC47699FB06B} since the same component with higher versioned keyfile exists
MSI (s) (D8:1C) [13:08:13:885]: Disallowing installation of component: {F7B290E8-4DDD-4C20-B3F8-5DD38608DFEF} since the same component with higher versioned keyfile exists

[MaximoTrinidad]

@SteveL-MSFT,

No wonder I didn't experience the issue before, as I got the habit of manually uninstall PScore,
I do have both GA and Preview installed.

I'm glad you found the root cause. Awesome!!

:)

[SteveL-MSFT]

@TravisEz13 and I looked at this and we believe the issue is understood. Basically, MSI is being "smart" keeping track of assemblies being installed along with their ids. We have two types of packages: stable and preview. But they both use the same ids for the same assemblies. So upon installing the preview, MSI sees that the assembly we are going to install is "already installed" because the id matches an assembly that is installed (even though it's in a different target file path).

The fix is to generate a different set of ids for the preview release for the assemblies so they don't match the stable ones. This is not as trivial as it sounds due to how packaging works today with WIX and we don't want to maintain two separate files.wxs that are 99% the same. We'll get this fixed for next preview.

[DarwinJS]

Maybe use a simple zip - with the assumption of file overwrites - for the preview?

[SteveL-MSFT]

@DarwinJS if you use the zip pkg we already release, you already won't have this problem, it's specifically the MSI pkg

[DarwinJS]

That's right - I forgot.
What if your team published a ps1 inside the preview folder that "self-installs" - basically does all the little things the MSI does?
This way we could unzip + run self-install and be done.
This would seem to be easy:

• to design and build - last I checked the MSI install was simple (might have changed) and the preview should actually be less integrated anyway
• for the powershell team to leave out unapplicable stuff like adding to the path
• easy for people doing self-installers or wrapping in other packaging technologies to get right
• easy for the preview chocolatey package to leverage