Unable to install/upgrade NuGet package provider
See original GitHub issueSystem 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?
Issue Analytics
- State:
- Created 4 years ago
- Reactions:4
- Comments:9
Top Results From Across the Web
When PowerShellGet v1 fails to install the NuGet Provider
Simply go to the PackageManagement package page on the PowerShell Gallery and under “Installation Options”, click on the “Manual Download” tab ...
Read more >Unable to install NuGet provider for PowerShell
In this article, you learned why you are unable to install NuGet provider for PowerShell. The solution to this problem is configuring TLS1.2...
Read more >How to Fix Unable to Install NuGet Provider in PowerShell
How to install NuGet packages from command line? Unable to install Azure/ NuGet provider for PowerShell Modules Install - PackageProvider ...
Read more >Install-PackageProvider cannot find the NuGet provider
Open PowerShell 7.1.3. Run the following command. Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201 -Force.
Read more >Unable to install Azure/NuGet provider for PowerShell Modules
Run the command Install-Module PowershellGet -Force. When asked to install NuGet provider, press Y and follow with Enter. After pressing Y and ...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
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 runInstall-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!
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
(orInstall-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.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:
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.
I’m moving this under PackageManagement since this seems to be a bug with Find-Package