ProGet Handling of PowerShell Gallery Versions

Michael.poutre_3915

Re: Proget keeps mangling NuGet package version numbers!
(It's assumed that the linked thread has been reviewed)

It looks like this is still an issue that doesn't appear to be fixed by PowerShell gallery. I'm not 100% positive if my issue is the same but it does appear to be. I've attached a few photos of the cached packages as well as an error example. I'm not too sure the flow behind the scenes, but hopefully somebody and chime in with some more information too. Right now this keeps us from being able to push this out os a Repository as end users will not want to deal with these errors.

I'm creating a post here to open this up to some discussion after speaking with @apxltd in Slack.

A simple solution I can think of that would provide a fix for users using this purely as a proxy/cache, would be to provide a toggle that makes ProGet ignore or even disable the "local" option.

Received Error:

Install-Module -Name ExchangeOnlineManagement -Verbose -Repository ProGet
VERBOSE: Repository details, Name = 'ProGet', Location = 'https://proget.company.com/nuget/PowerShell/'; IsTrusted = 'True'; IsRegistered = 'True'.
VERBOSE: Using the provider 'PowerShellGet' for searching packages.
VERBOSE: Using the specified source names : 'ProGet'.
VERBOSE: Getting the provider object for the PackageManagement Provider 'NuGet'.
VERBOSE: The specified Location is 'https://proget.company.com/nuget/PowerShell/' and PackageManagementProvider is 'NuGet'.
VERBOSE: Searching repository 'https://proget.company.com/nuget/PowerShell/FindPackagesById()?id='ExchangeOnlineManagement'' for ''.
VERBOSE: Total package yield:'2' for the specified package 'ExchangeOnlineManagement'.
VERBOSE: Repository details, Name = 'ProGet', Location = 'https://proget.company.com/nuget/PowerShell/'; IsTrusted = 'True'; IsRegistered = 'True'.
WARNING: 'ExchangeOnlineManagement' matched module 'ExchangeOnlineManagement/1.0.1' from provider: 'PowerShellGet', repository 'ProGet'.
VERBOSE: Repository details, Name = 'ProGet', Location = 'https://proget.company.com/nuget/PowerShell/'; IsTrusted = 'True'; IsRegistered = 'True'.
WARNING: 'ExchangeOnlineManagement' matched module 'ExchangeOnlineManagement/2.0.4' from provider: 'PowerShellGet', repository 'ProGet'.
Install-Package: /usr/local/microsoft/powershell/7/Modules/PowerShellGet/PSModule.psm1:9711
Line |
9711 |  … talledPackages = PackageManagement\Install-Package @PSBoundParameters
     |                     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | Unable to install, multiple modules matched 'ExchangeOnlineManagement'. Please specify an exact -Name and -RequiredVersion.

Example packages with issues(While reviewing these, i found more and more packages that run into this issue but did not want to list all of them):

ExchangeOnlineManagement
PSScriptAnalyzer
Az.Batch and most the Az.* packages

Az.Batch.png

Michael.poutre_3915

Also to note:

The feed page(https://proget.company.com/feeds/PowerShell) shows the incorrect latest version:

vs

atripp

Hi @Michael-poutre_3915 !

I'm not a PowerShell expert by any means, but there's nothing that's "quirky" about the ExchangeOnlineManagement package or data, so I don't think that's the problem.

What you're doing should work fine, however. It seems very basic usage, and it's just odd to see WARNINGS about the module being "matched"...

I searched the error "Unable to install, multiple modules matched " and found lots of results

Lots of suggestions, but this error seems to happen if there are repositories configured.... and apparently it's possible to have multiple repositories named ProGet?

So I'm wondering if this is ultimately some sort of client configuration quirk/bug?

Michael.poutre_3915

Hello @atripp ,

For reference, my current repositories:

PS /Users/userName> Get-PSRepository
Name                      InstallationPolicy   SourceLocation
----                      ------------------   --------------
PSGallery                 Untrusted            https://www.powershellgallery.com/api/v2
ProGet                    Trusted              https://proget.company.com/nuget/PowerShell/

The links you referenced are due to having multiple providers present. In this case, it appears the same provider is returning two package results instead of one. It looks like these errors are due to ProGet returning multiple versions when the FindPackagesById() is called with local and non local packages(In some cases, more detail below)

VERBOSE: Searching repository 'https://proget.company.com/nuget/PowerShell/FindPackagesById()?id='ExchangeOnlineManagement'' for ''.
VERBOSE: Total package yield:'2' for the specified package 'ExchangeOnlineManagement'.

I can't seem to find any documentation, but I believe PowerShellGet expects to only receive the latest version available unless a specific version is specified(This is based on the fact that if more than one package is found, it errors). Looking further into ProGet returning two results, we see that it is returning the latest non local version as well as the latest local version. This feels like a bug more than an intended action as the PowerShellGet Provider seems to be expecting only 1 result during an Install query.

VERBOSE: Searching repository 'https://proget.company.com/nuget/PowerShell/FindPackagesById()?id='ExchangeOnlineManagement'' for ''.
VERBOSE: Total package yield:'2' for the specified package 'ExchangeOnlineManagement'.
...
WARNING: 'ExchangeOnlineManagement' matched module 'ExchangeOnlineManagement/1.0.1' from provider: 'PowerShellGet', repository 'ProGet'.
...
WARNING: 'ExchangeOnlineManagement' matched module 'ExchangeOnlineManagement/2.0.4' from provider: 'PowerShellGet', repository 'ProGet'.

The below two examples show a problematic module, as well as a module that works for some reason. The InvokeBuild example Find-Module command returns 2 results instead of one. Normally, to get more than one result the command should be ran with the -AllVersions flag(Ref). In this case it again returns the latest local and non local version.

Moving to the platyPS example, for some reason only one result is returned(As would normally be expected)

PS /Users/userName> Find-Module InvokeBuild -Repository ProGet

Version              Name                                Repository           Description
-------              ----                                ----------           -----------
5.5.11               InvokeBuild                         ProGet               Build and test automation in PowerShell
5.7.3                InvokeBuild                         ProGet               Build and test automation in PowerShell

PS /Users/userName> Find-Module platyPS -Repository ProGet

Version              Name                                Repository           Description
-------              ----                                ----------           -----------
0.14.1               platyPS                             ProGet               Generate PowerShell External Help files from Markdown

atripp

Hi @Michael-poutre_3915,

It's strange indeed. I wonder if it's related to a locally cached version you have?

I can't seem to find any documentation, but I believe PowerShell expects to only receive the latest version available unless a specific version is specified(This is based on the fact that if more than one package is found, it errors). Looking further into ProGet returning two results, we see that it is returning the latest non local version as well as the latest local version. I think if ProGet were configured to only return the latest version that that would work better

Behind the scenes, PowerShell is calling the FindPackagesById() NuGet API method which is supposed to return all versions.

You should see almost identical results to:

You'll notice the same with InvokeBuild as well; all versions are returned from the API, as expected. So this is why I think there's multiple repositories (a local one?) or caching, or some other thing with the client. I know you can install a module locally, in powershell, by copying the module file to a directory?

Sorry I'm not really good with degubbing the PowerShellGet client, but hopefully we can figure it out....

Cheers,
Alana