DSInternals Chocolatey package has wrong PowerShell dependency

[bcurran3]

v3.3 has a dependency on powershell (= 3.0.20121027) instead of => 3.0.20121027 and thus won't install if PowerShell 4.x or 5.x is installed.

[MichaelGrafnetter]

Hi @bcurran3 , thanks for feedback. I actually did that intentionally because of these RTM OS versions:

• Windows 8
• Windows 8.1
• Windows Server 2012
• Windows Server 2012 R2

They already contain PowerShell v3 or v4 preinstalled and adding the dependency as => 3.0.20121027 would trigger an unnecessary PS v5 upgrade. Moreover, this operation requires a reboot.

On the other hand, the ChocolateyInstall.ps1 in the PowerShell v3 package contains this check:

  if ($PSVersionTable -and ($PSVersionTable.PSVersion -ge [Version]'3.0'))
  {
    Write-ChocolateySuccess "$packageName already installed on your OS"
    return
  }

So if PS v3, v4 or v5 is already preinstalled on the computer, the script will quit and the package will be marked as installed.

Do you know of any better solution that would upgrade PowerShell on Windows 7 (only contains PS v2), but leave the preinstalled version of PowerShell on newer operating systems, even if they do not have the latest PS version?

[bcurran3]

Hi MIke,

No. Sorry, the way you are doing it is wrong. You are currently FORCING it to install PS v3 instead of setting that as the bottom range. Chocolatey will install PS v3 if you have a version lessor or greater than it. Let me show you:

I had PowersShell v5.1 installed, and then after installing dsinternals-psmodule... my PS was forceably dowgraded. Look at the results for what Chocolatey package is installed for PowerShell:

So what you really need to do is set the PowerShell dependency as the minimum or higher just like the other dependencies. Yes, if Chocolatey doesn't have a PowerShell package installed, Chocolatey is going to install the latest version, BUT if Chocolatey has a PS package v3-v5 already installed, it shouldn't do anything as the PowerShell dependency will be satisfied within the range.

If you need a reference for versioning, look at:
https://docs.microsoft.com/en-us/nuget/reference/package-versioning

p.s. I HIGHLY recommend delisting the package right away before it downgrades more people!

[bcurran3]

p.s. I'll have to confirm the downgrade on another machine or two (Possibly I didn't have the Chocolatey PowerShell v5.1 package installed on the one I'm typing now. BUT, either way, I can't upgrade to PowerShell v5.1 because of the dependency for dsinternals-psmodule:

[bcurran3]

[ferventcoder]

They already contain PowerShell v3 or v4 preinstalled and adding the dependency as => 3.0.20121027 would trigger an unnecessary PS v5 upgrade. Moreover, this operation requires a reboot.

Hi Michael,
I agree that adding the dependency in that way would trigger an unnecessary upgrade. However, this is where things get tricky because taking an exact version dependency when it is really a minimum is incorrect behavior and can cause side effects like what @bcurran3 is seeing.

Do you know of any better solution that would upgrade PowerShell on Windows 7 (only contains PS v2), but leave the preinstalled version of PowerShell on newer operating systems, even if they do not have the latest PS version?

I can think of two possible resolutions here given that this is PowerShell:

• Simply run a check in the chocolateyInstall.ps1 script and fail if the user doesn't have at least PowerShell v3 (with a good message on how to resolve that of course)
• Or a package id specifically called powershell3.x (doesn't exist yet) for a dependency that induces the same behavior with a noop when a newer version is already installed

[ferventcoder]

PowerShell is one I've thought should have special handling, because some folks don't want PowerShell to upgrade unless they are intentional about it. We are looking at something similar with .NET Framework, where folks could take a dependency on a minimum version of the framework (based on an explicit package id with a version in the naming) and it would effectively noop if there is a newer .NET Framework installed. This would be used for dependencies - and then there is a .NET Framework package for folks that want an easy upgrade path. I see similar for PowerShell packages.

[MichaelGrafnetter]

Thanks for the thorough feedback, @ferventcoder and @bcurran3.

I can't upgrade to PowerShell v5.1 because of the dependency for dsinternals-psmodule

I obviously made a wrong decision and my limited tests on clean Windows machines did not point me to it, as everything got installed correctly.

Simply run a check in the chocolateyInstall.ps1 script and fail if the user doesn't have at least PowerShell v3 (with a good message on how to resolve that of course)

Done this in release 3.5.1, which is now waiting for approval.

Or a package id specifically called powershell3.x (doesn't exist yet) for a dependency that induces the same behavior with a noop when a newer version is already installed

Yep, I did that with dotnet4.5.1 right away, but I only found powershell and powershell4 among existing packages, no powershell3. IMO, the powershell v3.0.20121027 package already does a good job by nooping on newer versions of Windows and it would deserve a re-release as powershell3. PowerShell 3 was a major milestone and many modules take it as their baseline.

[MichaelGrafnetter]

BTW, what does the following message in Chocolatey Gallery mean?

This package skips automatic verification:

Requires PowerShell 5

[bcurran3]

PS5 requires a reboot post install. The Chocolatey testing environment doesn't reboot and then continue installing packages (at least currently, looks like there might be a possibility in the future based on some recent changes). An exemption from testing is required since a requirement of PS5 being already installed can't be be a true state (currently) in the Chocolatey testing environment.

[ferventcoder]

IMO, the powershell v3.0.20121027 package already does a good job by nooping on newer versions of Windows and it would deserve a re-release as powershell3. PowerShell 3 was a major milestone and many modules take it as their baseline.

I agree with your assessment here.