Add NuGet.exe to the Developer Command Prompt

[KirillOsenkov]

Please make NuGet.exe available from the Visual Studio Developer Command Prompt. It's a commonly needed tool and the expectation is that msbuild, dotnet and nuget just work from the command prompt.

[zhili1208]

is there any reason for this? we expect dotnet can replace nuget.exe in the future.

[KirillOsenkov]

Nuget.exe is a very useful tool used by millions of developers daily, it works for packages.config, project.json and PackageReferences. This need isn't going away anytime soon. Every time I'm on someone's machine helping someone, they take a long time to find NuGet.exe and run it.

There are situations where NuGet.exe works, but msbuild /r or dotnet restore don't.

Most of the users don't complain, so consider me being a voice to represent them. Thanks!

[dotMorten]

Agreed. This has always boggled my mind:

we expect dotnet can replace nuget.exe in the future.

Two years later, and it's still not a full replacement (no signing support for instance). Also I doubt it'll ever apply to C++'s .vcxproj projects that uses nuget packages too.

[timheuer]

Signing is my wish to @dotMorten #9006

[dotMorten]

@timheuer Agreed it's one of the two reasons I use nuget.exe. The other is I use nuget packages in my C++ projects, and they need explicit restore with nuget.exe or the msbuild-based CI build fails.

[dotMorten]

@timheuer Signing now works with "dotnet nuget sign". So it's probably just C++ projects left where we need this.

[KirillOsenkov]

nuget.exe is still needed for two important scenarios:

nuget pack custom.nuspec
nuget push

[timheuer]

nuget.exe is still needed for two important scenarios:

nuget pack custom.nuspec

dotnet pack myproj.csproj /p:NuspecFile=custom.nuspec

nuget push

dotnet nuget push ...

Solved?

[KirillOsenkov]

Not really. I don't want to have myproj.csproj. It's not a C# project. The fact that you need to have myproj.csproj to pack is a hack.

[nkolev92]

Correlating this issue to #4254.

I think it'd be great if #4254 is completed over this.

[KirillOsenkov]

#4254 would solve nuget pack, but it wouldn’t solve nuget push and nuget list.

[zivkan]

dotnet nuget push has existed since .NET Core 3.1 SDK. I'm not aware of any functionality differences between dotnet nuget push and nuget.exe push, except that the dotnet CLI uses more GNU style arguments, whereas nuget.exe uses PowerShell style arguments. But there's a 1:1 mapping between the two.

#6060 is the proposed replacement for list

[dotMorten]

@civkan package signing is one difference and I think there might be a few more. And it’s weird to use dotnet nuget to restore nuget packages for c++ projects (don’t even think that would work)

[zivkan]

does msbuild -t:restore -p:RestorePackagesConfig=true work? https://docs.microsoft.com/en-us/nuget/consume-packages/package-restore#restore-using-msbuild.

dotnet nuget sign was added in the .NET 6 SDK.

[nkolev92]

I took a look at all the NuGet.exe commands and generated a table for the behaviors

Command Name	Description	NuGet.exe	dotnet.exe	msbuild.exe	Notes
add	add package to hierarchical source	Yes	No	N/A	Parity not reached. No community asks I could find.
client-certs	Client certs management	Yes	Yes	N/A	Full parity.
config	Individual config items management	Yes	No. Community ask in 4855	N/A	No parity.
delete	Unlist package	Yes	Yes	N/A	Full Parity
init	init packages to a hierarchical source	Yes	No	N/A	Parity not reached. No community asks I could find.
install	Downloads a package and it's dependencies or run restore	Yes	Partially. No community ask for the install package.	N/A	Parity not reached. Not community asks for this
list	Search in sources	Yes	No	N/A	No parity.
locals	local folders and caches	Yes	Yes	N/A	Full parity
pack	pack nuspec/csproj	Yes	Yes 4254 is a gap.	Yes, msbuild will only ever support PackageReference pack.	Parity not reached. Scenario without parity has an easy workaround.
push	push package	Yes	Yes	N/A	Full parity
restore	restore package	Yes, both PR & PC	Yes (no PC support)	Yes, both PR and PC, PC is opt-in	Scoped parity. What this means is that dotnet.exe does not support old style, so there's no point to add restore support for that there.
search	Search in sources	Yes	No	N/A	No parity.
setapikey	set api key in config	Yes	No	N/A	No parity
sign	Sign package	Yes	Yes	N/A	Full parity
sources	manage sources	Yes	Yes	N/A	Full parity
spec	creates nuspec	Yes	No	N/A	No community asks
trusted-signers	manage trusted signers config	Yes	Yes	N/A	yes
update	updates	Yes	No	N/A	Not full parity, but the commands will work totally differently. Think packages.config vs PR. nuget.exe update never worked 100% correctly.
verify	verify packages	Yes	Yes	N/A	Full parity

Digesting the above table leads to the following list of relevant community requested issues, related to pack nuspec, setapikey, config, update and search commands

• Expand dotnet nuget to include more of the commands that nuget.exe has such as dotnet nuget config  #4855
• allow dotnet pack to pack nuspec file without needing a csproj file #4254
• Support for dotnet search command (equivalent to nuget.exe list, later search) #6060
• Why is there no 'dotnet nuget setApiKey' command? #6437
• support for bulk-updating references into csproj from commandline(s) - dotnet update package #4103

[dotMorten]

Even if the feature gap was closed, it still seems rather silly to me that you have to install the dotnet 6+ sdk just to restore or create nuget packages for non-dotnet projects (C++, .NET Framework etc).

[nkolev92]

Team Triage:
NuGet.exe can be downloaded from https://www.nuget.org/downloads. At this point we do not have any plans to add NuGet.exe to Visual Studio.

[fowl2]

Many, many components currently bundled with Visual Studio are downloadable separately. I'm not sure that's a compelling reason.

Note that "being able to run the command you found in the article you found online" and "not learn an alternative syntax" are a features not listed in the above table :)