You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 13, 2024. It is now read-only.
It downloads and installs the module without giving any output, warnings, or errors.
Actual behavior
On some machines, it gives the following error:
PackageManagement\Install-Package : No match was found for the specified search criteria and module name 'AzureArtifactsPowerShellModuleHelper'. Try Get-PSRepository to see all available registered module repositories.
At C:\temp\PowerShellGet\public\psgetfunctions\Install-Module.ps1:163 char:34
+ ... talledPackages = PackageManagement\Install-Package @PSBoundParameters
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (Microsoft.Power....InstallPackage:InstallPackage) [Install-Package], Ex
ception
+ FullyQualifiedErrorId : NoMatchFoundForCriteria,Microsoft.PowerShell.PackageManagement.Cmdlets.InstallPackage
I can reliably reproduce the issue on a Windows Server 2012 computer (output above is from this server), but have also had some co-workers running Windows 10 report the same issue. The command works fine on my machine though, which is running Windows 10.
Here is a screenshot of running various commands on the Windows Server 2012 computer when using PowerShellGet 2.2 downloaded via the PowerShell Gallery:
And here is a screenshot of the same commands running on the same Windows Server 2012 computer using the latest code on the master branch, commit sha d6b0808 (has same output as above screenshot):
In the above screenshots you should be able to ignore the warnings, as it's just complaining that it can't connect to our Azure Artifacts feed because it doesn't have credentials, but the module it's being told to install lives on the public PowerShell Gallery here.
Here is a screenshot of running the same Install-Module command on my local Windows 10 machine, and the command working as expected:
It seems that using -MaximumVersion, regardless of what version number it's given (i.e. an existing version or a non-existent one), causes the command to fail. -MinimumVersion and -RequiredVersion seem to work properly; it's only -MaximumVersion that results in the module not being found and thus, not installed.
I also tried Find-Module and it seems to have the exact same problem. If any -MaximumVersion is specified it is unable to locate the module in the PowerShell gallery, but only on some computers. I assume that Install-Module is using Find-Module under the hood, but haven't looked at the code yet to verify.
The reason I'm wanting to use -MaximumParameter is to avoid having our PowerShell scripts automatically download new major versions of modules, as those are likely to include breaking changes (assuming the module follows semantic versioning), thus allowing our scripts to use new versions of modules (such as auto-updating to use 2.7 from 2.6), but preventing them from updating to new versions with breaking changes (such as auto-updating to 3.0). Until this bug is fixed, our workaround is to specify a -RequiredVersion instead, but that's not ideal.
The text was updated successfully, but these errors were encountered:
After a bit more investigation, it seems that after I remove my Azure Artifacts PSRepository (which requires credentials to access) from the Windows Server 2012 machine, then Find-Module and Install-Module work as expected. So the bug seems to be that when any of the registered PSRepositories requires credentials to access, then Find-Module with MaximumVersion doesn't work for any of the registered PSRepositories, even ones that do not require credentials.
Steps to reproduce
Expected behavior
It downloads and installs the module without giving any output, warnings, or errors.
Actual behavior
On some machines, it gives the following error:
Environment data
Windows Server 2012
More Info
I can reliably reproduce the issue on a Windows Server 2012 computer (output above is from this server), but have also had some co-workers running Windows 10 report the same issue. The command works fine on my machine though, which is running Windows 10.
Here is a screenshot of running various commands on the Windows Server 2012 computer when using PowerShellGet 2.2 downloaded via the PowerShell Gallery:
And here is a screenshot of the same commands running on the same Windows Server 2012 computer using the latest code on the
master
branch, commit sha d6b0808 (has same output as above screenshot):In the above screenshots you should be able to ignore the warnings, as it's just complaining that it can't connect to our Azure Artifacts feed because it doesn't have credentials, but the module it's being told to install lives on the public PowerShell Gallery here.
Here is a screenshot of running the same
Install-Module
command on my local Windows 10 machine, and the command working as expected:It seems that using
-MaximumVersion
, regardless of what version number it's given (i.e. an existing version or a non-existent one), causes the command to fail.-MinimumVersion
and-RequiredVersion
seem to work properly; it's only-MaximumVersion
that results in the module not being found and thus, not installed.I also tried
Find-Module
and it seems to have the exact same problem. If any-MaximumVersion
is specified it is unable to locate the module in the PowerShell gallery, but only on some computers. I assume thatInstall-Module
is usingFind-Module
under the hood, but haven't looked at the code yet to verify.The reason I'm wanting to use
-MaximumParameter
is to avoid having our PowerShell scripts automatically download new major versions of modules, as those are likely to include breaking changes (assuming the module follows semantic versioning), thus allowing our scripts to use new versions of modules (such as auto-updating to use 2.7 from 2.6), but preventing them from updating to new versions with breaking changes (such as auto-updating to 3.0). Until this bug is fixed, our workaround is to specify a-RequiredVersion
instead, but that's not ideal.The text was updated successfully, but these errors were encountered: