Catastrophic terminating error for PSGallery-installed "Update-Module" due to repo URL syntax change #349
Description
ISSUE
SourceLocation PSGallery default URL at some point has changed slightly in it's stored syntax.
I have about half of my systems (many) (all Win7x64 PoSH 5.1 latest) that I have been testing today that all have this as the default URL (you cannot even manually force the PSGallery repo URL):
(NOTE THE TRAILING SLASH ON "SourceLocation"):
`λ Get-PSRepository psgallery | fl
Name : PSGallery
SourceLocation : https://www.powershellgallery.com/api/v2/
Trusted : True
Registered : True
InstallationPolicy : Trusted
PackageManagementProvider : NuGet
PublishLocation : https://www.powershellgallery.com/api/v2/package/
ScriptSourceLocation : https://www.powershellgallery.com/api/v2/items/psscript
ScriptPublishLocation : https://www.powershellgallery.com/api/v2/package/
ProviderOptions : {}
`
And the other half (also MANY) with this as the default URL:
(NOTE NO TRAILING SLASH ON "SourceLocation"):
`λ Get-PSRepository psgallery | fl
Name : PSGallery
SourceLocation : https://www.powershellgallery.com/api/v2
Trusted : True
Registered : True
InstallationPolicy : Trusted
PackageManagementProvider : NuGet
PublishLocation : https://www.powershellgallery.com/api/v2/package/
ScriptSourceLocation : https://www.powershellgallery.com/api/v2/items/psscript
ScriptPublishLocation : https://www.powershellgallery.com/api/v2/package/
ProviderOptions : {}
`
Why is this relevant? Diff the PSGetModuleInfo.xml from either "flavor" from each and every PSGallery-installed module, and look at line 143 and it becomes clear that this syntax difference above actually made it into the stored config files:
And why does that matter? Purely as an example, if you simply copy (or distribute) all the modules installed on an Internet-facing machine to one that is not (and has the opposite URL config), and then attach it to the Internet and run a simple Update-Module * -Verbose, you get a xmas tree of red and catastrophic failures as shown here:
Versus this, from the half of systems with the other "flavor" PSGallery URL:
Cause
Given the two above runs are the exact same copied PSGallery installed modules placed in C:\Program Files\WindowsPowershell\Modules, and both were reset/defaulted PSGallery sources as shown above, other than this needing to be addressed is when you perform a Register-PSRepository -Default clearly something changed along the way and I cannot find the root source of that URL. Where is it defined so that I can even look at these systems to determine if the URL definition is different or whether it was a specific code/version issue?
The catastrophic issue risk is if later it is ever necessary to re-register the PSGallery using the command Register-PSRepository -Default after unregistering. Because, when the URL then is changed to the (apparently) newer no trailing slash, 100% of the already installed PSGallery modules will then throw the above terminating errors upon attempting to update. At that point, the only workaround I have found is to first have to determine each and every one who's PSGetModuleInfo.xml is now incorrect and was stored with the trailing slash, and then force a fresh re-install and not update using Install-Module -Force. At that point, I can confirm the new PSGetModuleInfo.xml is stored with whatever is the current repo URL, so without the slash. Then and only then will Update-Module ever work on that system again for those modules.
To further prove this root cause, one can also manually edit the PSGetModuleInfo.xml and remove the erroneous legacy trailing slash from the PSGallery URL and without even a session restart re-run the Update-Module * -Verbose and there will now be no errors and all module updates will be successful.
Steps to reproduce
Update-Module * -Verbose
VERBOSE: Checking for updates for module 'WinFormPS'.
PackageManagement\Install-Package : Unable to find repository
'https://www.powershellgallery.com/api/v2/'. Use Get-PSRepository to see all available
repositories.
At C:\Program Files\WindowsPowerShell\Modules\PowerShellGet\2.0.0\PSModule.psm1:12979
char:20
+ ... $sid = PackageManagement\Install-Package @PSBoundParameters
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (Microsoft.Power....InstallPackage:InstallPa
ckage) [Install-Package], Exception
+ FullyQualifiedErrorId : SourceNotFound,Microsoft.PowerShell.PackageManagement.Cmdlet
s.InstallPackage
Expected behavior
Updating of all modules occurs for same set of PSGallery installed modules successful and fails on others. Expect consistent gallery source URL across all versions of PoSH and module.
Actual behavior
See Above
Environment data
> $PSVersionTable
λ $PSVersionTable
Name Value
---- -----
PSVersion 5.1.14409.1012
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.14409.1012
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1> Get-Module -ListAvailable PowerShellGet,PackageManagement
I literally deleted all versions of powershellget and packagemanagement back to 1.0.0.1 2017 (NOTE I started testing with the latest v2.0.1 with same results and worked backwards) and can not replicate a reset of the psgallery URL to now place the trailing slash on it as is shown in probably half (many) of the systems I have seen. All WIN7x64 in this issue/testing PS5.1. Some probably were upgraded through v4 PoSH while perhaps others went directly to 5.x but because I have not yet confirmed what is responsible for setting up the default PSGallery URL, I cannot confirm whether there is a correlation between the PoSH upgrade paths vs just being a module/assembly issue, or perhaps arbitrary code that tacked it on before storing it in the xml repo file. However, at some point there was a combination of PoSH versions, Packagemanagement module, and Powershellget module that was allowing the trailing slash systems to update.
> Get-PackageProvider -ListAvailable
Directory: C:\Program Files\WindowsPowerShell\Modules
ModuleType Version Name ExportedCommands
---------- ------- ---- ----------------
Script 1.1.1.0 PackageManagement {Find-Package, Get-Package, Ge...
Binary 1.0.0.1 PackageManagement {Find-Package, Get-Package, Ge...
Script 1.0.0.1 PowerShellGet {Install-Module, Find-Module, ...