The other day I was working on something in a largish .Net codebase where there were a lot of Nuget packages that needed work. Most of the time the main tool for this is the Nuget Package Manager, the standard UI, and this is fine for one-at-a-time scenarios. However for more “heavy duty” usages, it can help to drop down to the built-in PowerShell prompt.
There are a bunch of PowerShell commandlets for dealing with Nuget packages, and if you’re working in Visual Studio, the module is pre-loaded and ready to use. Simply go to Tools -> Nuget Package Manager -> Package Manager Console and you’ll be presented with a PowerShell prompt. If you’re not familiar with it, PowerShell is a scripting language that has been part of Windows for a while now. It offers everything a standard command prompt would, plus a lot of other stuff, even offering interoperability with .Net to make it a really powerful tool. PowerShell has some guiding principles, among which is discoverability, and most public modules will provide really strong documentation. To access this, there’s a Get-Help commandlet, that will show the help for a module or commandlet. For example, to see help for the Nuget module, you can simply type:
If you’re not sure what modules are available, you can use Get-Module for a list. Note how the module name was the parameter in the previous example; this same technique can be used for any module. Visual Studio by default just loads the Nuget module, but you might find that some of the packages in your solution import modules of their own (Entity Framework is a good example of this), and these will also be listed here.
The PowerShell Nuget commandlets offer a few useful things that the UI doesn’t; one of these that I use fairly often are the extra parameters for installing or update packages. The -Reinstall parameter on Update-Package will run the install script again, adding binding redirects, references and so on, while maintaining the same version. The -IgnoreDependencies one is a bit risky – it does what it says; it’s up to you to judge whether that’s what you really mean. You can also specify to use a particular Source, run as a WhatIf, and various other options that you wouldn’t get in the UI.
Beyond this, PowerShell is a fully-featured scripting language, and you can script any workflow you like here. In the particular case I had, I wanted to remove all packages by a search term, with all their dependencies (cascading). Doing this in the UI is very repetitive, but with PowerShell we can do this:
What this is doing is:
- Getting all the package references for all projects in the solution
- Filtering them by wildcard search for a search term
- Piping these, i.e. passing the results, into a ForEach loop
- For each package, calling Uninstall-Package, removing this package reference from the particular project with some parameters to set the behavior
Knowing about things like this can save quite a bit of time; it’s not necessarily an every day use case, but when it comes up it really makes a difference to have the right tools available!