Unable to install/upgrade NuGet package provider

[nathan-alden-hp]

System information:

• Fresh installation of Windows 10 Pro 1809 in a Hyper-V VM
• Latest Windows Updates
• PowerShell Core 6.2.2

All I am trying to do is update my NuGet package provider and my PackageManagement and PowerShellGet modules. I have read many blogs and Stack Overflow questions where people have similar issues to mine, but it seems that nothing works. To rule out any misconfigurations on my developer workstation, I created a fresh Windows 10 Pro 1809 VM in Hyper-V and installed all Windows Updates. Then I installed PowerShell Core 6.2.2. Here are some queries that show some important information:

PS > Get-PackageProvider NuGet

Name                     Version          DynamicOptions
----                     -------          --------------
NuGet                    3.0.0.1          Destination, ExcludeVersion, Scope, SkipDependencies, Headers, FilterOnTag, Contains, AllowPrereleaseVersions, ConfigFile, SkipValidate

PS > Get-Module -ListAvailable PackageManagement,PowerShellGet

    Directory: C:\program files\powershell\6\Modules

ModuleType Version    Name                                PSEdition ExportedCommands
---------- -------    ----                                --------- ----------------
Script     1.3.2      PackageManagement                   Desk      {Find-Package, Get-Package, Get-PackageProvider, Get-PackageSource…}
Script     2.1.3      PowerShellGet                       Desk      {Find-Command, Find-DSCResource, Find-Module, Find-RoleCapability…}

PS > Get-PSRepository

Name                      InstallationPolicy   SourceLocation
----                      ------------------   --------------
PSGallery                 Untrusted            https://www.powershellgallery.com/api/v2

When I attempt to install the NuGet package provider to be sure I have the latest version, I get this:

PS > Install-PackageProvider NuGet -Force -Verbose
VERBOSE: Using the provider 'Bootstrap' for searching packages.
VERBOSE: Finding the package 'Bootstrap::FindPackage' 'NuGet','','','''.
Install-PackageProvider : No match was found for the specified search criteria for the provider 'NuGet'. The package provider requires 'PackageManagement' and 'Provider' tags. Please check if the specified package has the tags.
At line:1 char:1
+ Install-PackageProvider NuGet -Force -Verbose
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : InvalidArgument: (Microsoft.PowerShel\u2026tallPackageProvider:InstallPackageProvider) [Install-PackageProvider], Exception
+ FullyQualifiedErrorId : NoMatchFoundForProvider,Microsoft.PowerShell.PackageManagement.Cmdlets.InstallPackageProvider

Can you help me resolve this issue?

[SydneyhSmith]

@nathan-alden-hp thanks for reporting this issue, we are able to repro it and it looks like a potential bug in Package Management specific to finding nuget...we are doing some further investigation--Thanks!

[alerickson]

I'm moving this under PackageManagement since this seems to be a bug with Find-Package

[Denney-tech]

This appears to still be an issue. Was testing an old script that needed a minimum version of NuGet, got the OP's error message about lacking tags when ran in pwsh 7. So I switched over to posh 5.1 where the script was originally written, and it downgraded NuGet from 3.0.0.1 to 2.8.5.208. This is just above the minimum version requirement in the script, so I'm fine for production needs, but I'm going to have to figure out how to update NuGet back to latest again.

Edit: So the downgrade only occurred in posh, pwsh still sees 3.0.0.1. Still weird that pwsh doesn't recognize nuget as a package provider.

[joshieecs]

The workaround to fix this is to manually delete all but the base versions of your PackageManagement and PowerShellGet modules. Run $env:PSModulePath from powershell if you don't know where to look. There will be a folder for each package, and subfolders named with the version number. On my setup, I deleted all the version subfolders except 1.0.0.1 for both modules. (I use Windows powershell 5.1, I don't know what the base versions might be for other installs.)

Then run Install-Module PowerShellGet -Force and it will update your PowerShellGet module, and your PackageManagement module as a dependency. The latest NuGet provider is included in the latest PackageManagement package. Do NOT run Install-PackageProvider nuget again, or it will revert you to the outdated Bootstrap version, and you will have to repeat this process.

I did some research into what's going on and here are my findings:

Following Microsoft Docs for Installing PowerShellGet (updated Sep-19-2019 -- not old)

You would be instructed to run Install-PackageProvider -Name NuGet -Force

This installs NuGet 2.8.5.208 from Bootstrap!

PS C:\Users\Joshua> Find-PackageProvider Nuget | ft -Property Name, ProviderName, Source, Summary -Wrap

Name  ProviderName Source                                                                    Summary                                 
----  ------------ ------                                                                    -------                                 
nuget Bootstrap    https://onegetcdn.azureedge.net/providers/nuget-2.8.5.208.package.swidtag NuGet provider for the OneGet           
                                                                                             meta-package manager

Interestingly, it installs to C:\Program Files\PackageManagement\ProviderAssemblies\nuget\2.8.5.208 rather than your $env:PSModule path where it belongs. I think that is very outdated behavior.

However, if you Install-Module PackageManagement (or Install-Module PowerShellGet for which PackageManagement is a dependency), it installs the the newest version of PackageManagement (currently 1.4.7) and PackageManagement contains a NuGet provider version reported as 3.0.0.1.

PS C:\Users\Joshua> Get-PackageProvider Nuget | ft -Property Name, Version, ProviderPath

Name  Version ProviderPath                                                                                                           
----  ------- ------------                                                                                                           
NuGet 3.0.0.1 C:\Program Files\WindowsPowerShell\Modules\PackageManagement\1.4.7\fullclr\Microsoft.PackageManagement.NuGetProvider...

It's actually version 3.0.0.2, but it reports as 3.0.0.1.

Looking through the PackageManagement repo on Github (github.com/OneGet/oneget) for tag 1.4 release is instructive. In the src directory, it seems that Microsoft.PackageManagement.NuGetProvider links to a specific tree of the OneGet/NuGetPackageProvider repo which includes a file releasenotes.md which says:

3.0.0.2 What's new?

Packaged as a NuGet package on https://powershell.myget.org/feed/Packages/powershellmodule

3.0.0.1 What's new?

Now supports NuGet v3 URLs, like https://api.nuget.org/v3/index.json

So the Windows file property version isn't making things up about the 3.0.0.2 version. I am not sure why Get-PackageProvider is showing a different version. I can't access the powershell.myget.org link to see what's there, because it asks for a login.

The problem is that Find-PackageProvider can't find any versions of NuGet on PSGalley... because none exist on PSGallery! (They must be in the private repo.) So it resorts to the Bootstrap source. I don't use pwsh core, but seems from the other posts here that the Bootstrap doesn't have a value except on Windows powershell.

Making a wild guess: perhaps the NuGet provider is intended to be managed exclusively through updates to the PackageManagement module now.

I do seem to recall that some years ago when PackageManagement was still called OneGet, the NuGet provider was on PSGallery and could be serviced through Install-PackageProvider. So the Windows documentation was probably correct at some point in the past.

The easiest solution would be for Find-PackageProvider to stop installing the old Bootstrap version without someone explicitly using the -ForceBootstrap option. Just using -Force alone should not fall back to the Bootstrap. But that won't stop people from being thoroughly confused. I would suggest removing or updating the Bootstrap, but that might break someone's old vanilla Windows PowerShell install.

The package file the Bootstrap downloads is this: https://onegetcdn.azureedge.net/providers/nuget-2.8.5.208.package.swidtag.

Alternatively, the OneGet/NuGetProvider team could start releasing the NuGet Provider on PSGalley instead of a private feed. That would make everything work as intended.

However, it looks like there is an unrelated DSC module already using the name "NuGet" on PSGallery, but it was last updated in 2016. Perhaps the NuGetProvider team could contact the owner (appears to be powershell.org) or, if it's been abandoned, ask the PSGallery admins to rename it to "NuGetDsc" or something.

It does have almost 200k downloads, but I wonder how many were really people looking for a NuGet DSC module and how many were people trying to install or update NuGet or the NuGet PackageProvider? 😂 Seems like an important enough name to have reserved. Interestingly, the it's github repo says it was named originally cNuGet.

[Rajkishore123]

Check out if the below solution works for you

Install-packageprovider no match was found for the specified search criteria for the provider ‘nuget’

[turagittech]

This is blocking running PowerShell core in Azure Pipelines I rasied it as an Azure issue, not realising at the time it affected all PowersShell Core versions. Be great to see this resolved soon https://developercommunity.visualstudio.com/content/problem/1176617/azure-devops-windows-2019-agent-powershell-core-wo.html

[paulomarquesc]

Any updates on this? We are also having the same issue but on Powershell 7 on Linux and Windows.

[sabuncu]

I am having this problem on Windows 10 20H2 OS Build 19042.867 for PowerShell Core 7.1.2.

The most-widely suggested fix involving setting SecurityProtocol to TLS12 does not help.

As a workaround, I am using the desktop version.

[sabuncu]

delete all but the base versions of your PackageManagement and PowerShellGet modules.

@joshieecs What do you mean by deleting base versions?

My $env:PSModulePath is as follows:

C:\Users\AMS\Documents\PowerShell\Modules - Folder does not exist. C:\Program Files\PowerShell\Modules - Folder does not exist. C:\Program Files\PowerShell\7\Modules - Contains some modules. C:\Program Files\WindowsPowerShell\Modules - Contains many modules. C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules - Contains many modules. C:\Program Files (x86)\Microsoft SQL Server\150\Tools\PowerShell\Modules - Contains one module (SQLPS) only.

Thank you.