NuGet frequently-asked questions

All the information around both UI and command-line tools is available in the Install guide.

The command-line tool, nuget.exe, builds and runs typically under Windows. NuGet can run on Unix operating systems using mono, but it is not officially supported by NuGet's Support Policy.

Mono has transferred ownership to Wine and is no longer maintained by Microsoft.

The primary source for learning about a package is its listing page on nuget.org (or another private feed). Each package page on nuget.org includes a description of the package, its version history, and usage statistics. The Info section on the package page also contains a link to the project's web site where you typically find many examples and other documentation to help you learn how the package is used.

For more information, see Finding and choosing packages.

• Visual Studio on Windows supports the Package Manager UI and the Package Manager Console.
• Visual Studio for Mac has built-in NuGet capabilities as described on Including a NuGet package in your project.
• Visual Studio Code (all platforms) does not have any direct NuGet integration. Use the NuGet CLI or the dotnet CLI.
• Azure DevOps provides a build step to restore NuGet packages. You can also host private NuGet package feeds on Azure DevOps.

In Visual Studio, use the Help > About Microsoft Visual Studio command and look at the version displayed next to NuGet Package Manager.

Alternatively, launch the Package Manager Console (Tools > NuGet Package Manager > Package Manager Console) and enter $host to see information about NuGet including the version.

NuGet generally works for .NET languages and is designed to bring .NET libraries into a project. Because it also supports MSBuild and Visual Studio automation in some project types, it also supports other projects and languages to various degrees.

The most recent version of NuGet supports C#, Visual Basic, F#, WiX, C++, and Q#.

NuGet has full support for a variety of project templates like Windows, Web, Cloud, SharePoint, Wix, and so on.

Go to the Updates tab in the Package Manager UI and select Update All, or use the Update-Package command from the Package Manager Console.

To update the template itself, you need to manually update the template repository. See Xavier Decoster's blog on this subject. Note that this is done at your own risk, because manual updates might corrupt the template if the latest version of all dependencies are not compatible with each other.

Yes, NuGet works directly from the command line. See the Install guide and the CLI reference.

See the Install guide. To check the current installed version of the tool, use nuget help.

You are allowed to redistribute nuget.exe under the terms of the MIT license. You are responsible for updating and servicing any copies of nuget.exe that you choose to redistribute.

Yes, it's possible to add custom commands to nuget.exe, as described in Rob Reynold's post available via Archive.org.

The top-level object in the Visual Studio automation object model is called the DTE (Development Tools Environment) object. The console provides this through a variable named $DTE. For more information, see Automation Model Overview in the Visual Studio Extensibility documentation.

This is a known issue with how PowerShell interacts with a COM object. Try the following:

`$dte2 = Get-Interface $dte ([EnvDTE80.DTE2])`

Get-Interface is a helper function added by the NuGet PowerShell host.

See Creating and publishing a package.

See Supporting Multiple .NET Framework Versions and Profiles.

See the Hosting packages overview.

See Bulk publishing NuGet packages (jeffhandly.com).

Yes, see Scott Hanselman's Blog post How to access NuGet when nuget.org is down (or you're on a plane) (hanselman.com).

Set the repositoryPath setting in Nuget.Config using nuget config -set repositoryPath=<path>.

Set the disableSourceControlIntegration in Nuget.Config to true. This key works at the solution level and hence need to be added to the $(Solutiondir)\.nuget\Nuget.Config file. Enabling package restore from Visual Studio creates this file automatically.

See Enabling and disabling package restore.

You need to select the All source when installing a local package into the project. This aggregates all the feeds instead of using just one. The reason this error appears is that users of a local repository often want to avoid accidentally installing a remote package due to corporate polices.

In most projects where separate projects live in separate folders, this is not a problem as NuGet identifies the packages.config files in each project. With NuGet 3.3+ and multiple projects in the same folder, you can insert the name of the project into the packages.config filenames use the pattern packages.{project-name}.config, and NuGet uses that file.

This is not an issue when using PackageReference, as each project file contains its own list of dependencies.

• Add https://api.nuget.org/v3/index.json to your list of sources, or
• Delete %appdata%\.nuget\NuGet.Config (Windows) or ~/.nuget/NuGet/NuGet.Config (Mac/Linux) and let NuGet re-create it.

In packages.config projects, when a package with build props or targets was installed, NuGet would add an EnsureNuGetPackageBuildImports target to verify that the packages msbuild content has been imported before building. If the target has been modified manually, NuGet might not be able to detect that it needs removed when migrating.

If your project is PackageReference and you still have this target in project file, it should be safe to remove.