Expand dotnet nuget to include more of the commands that nuget.exe has such as dotnet nuget config

[automatonic]

dotnet msbuild is clever about its project/solution context and knows how to find the right version of msbuild to support the task at hand. This is especially useful for a build agent doing CI/CD work where there are potentially many projects with potentially many tool/sdk/runtime version profiles.

I think this is equally valuable in dotnet nuget commands, as evidenced by the existence of:

• dotnet nuget delete
• dotnet nuget locals
• dotnet nuget push
• dotnet pack (i assume)

But when working through automation tasks, I immediately wanted:

• dotnet nuget sources

I was trying to dynamically build a nuget.config file at the solution level that had the correct PAT/credentials (secret build variables) to access a private nuget feed on a multi-tenant build agent without checking in secrets.

I could also see an argument for:

• dotnet nuget config
• dotnet nuget delete
• dotnet nuget setapikey

I mentioned this to Nate McMaster here, and he encouraged me to take it up in this repository.

Thanks for your time and consideration. Please let me know if there is a better/preferred channel in which to request this sort of feature set.

[rrelyea]

Thanks for your asks. Helps us to prioritize future work here.
/cc @anangaur

[mishra14]

Another request: https://github.com/dotnet/cli/issues/7339

[natemcmaster]

+1 for dotnet nuget sources for adding credentials. This is important to us as we've been asked to switch to VSTS private feeds.

[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	Yes	N/A	Full 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	No	N/A	Parity not reached.
list	Search in sources	Yes	Yes	N/A	Full 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	Yes	N/A	Full 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

I took a crack at comparing all the commands in nuget.exe and dotnet.exe.
Given that most of the issues in here have a lot of upvotes themselves, I'll convert this to dotnet nuget config as it's the only command leftover in the list that doesn't have it's own popular issue.

[nkolev92]

cc @erdembayar I know dotnet nuget config was of interest to you.

[smarts]

Upvoting setapikey command 👍🏽 because the current implementation requires private/security data to be stored in plaintext on non-Windows environments, which is a pretty egregious problem.

[akoeplinger]

@nkolev92 we had multiple internal teams at MSFT who are doing a migration to Mariner reach out to us when moving from Mono's nuget(which is just the nuget.exe CLI) to the dotnet CLI and one common pain point was the missing support for the install command.

Most of these teams are not even using .NET but have some tool which is hosted on an internal AzDO feed and they were using nuget install <tool> e.g. from CMake to grab the assets. Right now you need to create a dummy .csproj like this so you can run dotnet restore on it which makes this a lot more complicated:

<Project Sdk="Microsoft.NET.Sdk">

<PropertyGroup>
   <OutputType>Exe</OutputType>
   <TargetFramework>net6.0</TargetFramework>
   <RestorePackagesPath>packages</RestorePackagesPath>
</PropertyGroup>

<ItemGroup>
  <PackageDownload Include="Some.Internal.Tool" Version="[7.0.7]" />
</ItemGroup>

</Project>

It'd be great if we could get dotnet nuget install supported in the future 😄

[nkolev92]

@akoeplinger Mind creating a new issue for that?
We don't really have a tracking issue for that ask yet.

[akoeplinger]

I filed #12513 for the "dotnet nuget install" issue.

[nkolev92]

Updated the map + the doc in NuGet/docs.microsoft.com-nuget#3303.

Given that this was converted to track dotnet nuget config was completed, I'm gonna close this.

#13398 tracks the documentation.