NuGet requires Visual Studio 2010 or Visual Web Developer Express 2010. The NuGet Package Manager Console requires that PowerShell 2.0 be installed. Powershell 2.0 is already installed if you have the following operating system:
If you have the following operating systems, you must manually install Powershell 2.0.
Not at all. For information about how to install NuGet without MVC 3, see Installing NuGet.
Check the Known Issues page. Typically, the issue is due to having an older version of the Reflector add-in installed or not having PowerShell 2.0 installed (as in the case of Windows XP).
See the Creating and publishing a package page.
A solution-level package has to be installed only once in a solution to be available for all projects in the solution. A project-level package must be installed separately in each project where you want to use it. For solution-level packages, NuGet doesn't change anything in a project, whereas in a project-level package it does. Typically, a solution-level package installs new commands that can be called from within the Package Manager Console window.
See the section titled "Supporting Multiple .NET Framework Versions and Profiles" in Creating a Package.
In Visual Studio go to the Help > About Microsoft Visual Studio menu and look for NuGet Package Manager. The version is displayed next to that entry.
Alternatively, you can launch the Package Manager Console and type in $host
to output information about NuGet
Powershell host including the version.
The console provides a variable named $DTE
that returns the DTE
object. See the Get-Project
command in
Package Manager Console Powershell Reference.
Select the All node when installing your local package. The all* node aggregates all the feeds. When you select a specific repository under the Online tab, that restricts installation to just that node. The reason for this behavior is that in many cases, users of a local repository don't want to accidentally install a remote package due to corporate polices.
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 Hosting Your Own NuGet Feeds.
Sorry, no. But keep reading. NuGet does not work with Nu Gems directly, because NuGet uses its own package format (based on OPC) and cannot read .gemspec files directly. In essence, NuGet can be considered Nu Gems Version 2 and an evolution of package management for Visual Studio and the .NET Framework platform. If you liked the Nu behavior of dealing with packages, note that NuGet.exe behaves very similarly for those who want to use NuGet outside of Visual Studio.
The command-line application (nuget.exe) builds and runs under Mono and allows you to create packages in Mono. This is especially true for Mono on Windows, but there are some known issues for Mono on Linux and OS X. To review the known issues, search for Mono in our issue list.
Yes there is! See David Ebbo's Blog post entitled Installing NuGet Packages directly from the command line.
Keep in mind that the focus of NuGet is to let you modify your projects and add references to Visual Studio projects. The command line tool, NuGet.exe, will download and unpack packages, but it won't automate Visual Studio and modify your project files. Within Visual Studio, there are two clients for NuGet: the PowerShell-based Package Manager Console and the Manage NuGet Packages dialog box. Both are wrappers around the NuGet API, which is written in managed code. NuGet.exe is also used to create and publish packages.
NuGet currently supports C#, F# and Visual Basic projects.
You sure can! As discussed in the question on command line tools for NuGet, the primary focus of NuGet is Visual Studio, but the core NuGet API has no dependencies on Visual Studio. There are multiple NuGet clients that work completely outside of Visual Studio: