Home: All NuGet Package Manager Console operations should work from the command line

[madelson]

We use NuGet heavily to manage both internal and external dependencies for our .NET framework apps. We are continually frustrated by the lack of automation support for NuGet operations, primarily because many core operations (e. g. Update-Package) are not available outside of visual studio.

Some of these operations are provided by the NuGet CLI, but they do not actually do the same thing as the VS package manager console versions to the point of being largely useless for automation purposes. Some deal-breaking discrepancies we've noted:

• CLI will add extraneous app.config/web.config files
• CLI will not add new dependencies to packages.config/csproj
• CLI does not properly handle content files
• Probably other things (install.ps1 scripts?)

It would be great if there were a command line tool which could provide the same functionality as Visual Studio-based updates. None of the operations seem terribly complex; it's largely just editing XML files. I could see replicating the install.ps1 environment being a challenge, but my guess is that 99% of install.ps1 files only rely on a tiny portion of this (mostly the ability to add/remove project items).

NuGet product used (NuGet.exe, VS Package Manager Console):
NuGet version: 4.4.1
VS version: 2017
OS version: Windows 7

[jainaashish]

Most of the NuGet operations need to access project system in order to update projects metadata or properties like for an update operation, it needs to remove the existing reference and add a new reference for the updated version. Similarly there are other caveat like adding content files into project or running ps1 scripts which in most cases also requires dte instance. Because of these constraints, NuGet CLI can't behave similar to package management console. NuGet.exe does support install/update operations but with limited capabilities and that only for packages.config based projects. They are not even supported for PackageReference which is where we're heading to.

But we do realize the potential of having a CLI to support these NuGet operations which is there is dotnet.exe which supports add command which works similar to nuget.exe install and going forward, we'll add more support in dotnet.exe for other commands like update.

[madelson]

Thanks @jainaashish for the detailed response.

I guess I'd like to push back on the claim that the NuGet operations cannot be done without the full VS environment. It seems to me that there are fixed steps involved:

• Unzipping the package
• Editing csproj to add/remove references to DLLs and content files
• Copying content files into the appropriate directory
• Running transforms for template files
• Editing packages.config
• Running install.ps1
• Determining/installing dependencies as needed (just requires reading packages.config)

For editing the csproj, this is a simple XML edit; while it's probably a bit easier via the VS API replicating this with plain .NET code shouldn't be that bad.

The install.ps1 script is more difficult because the powershell function is allowed to take in some VS environment objects as arguments. Even for that, though, my guess is that 99% of packages don't even have such a script and of the ones that do only a tiny percentage use the VS objects for anything other than basic csproj edit operations. That means that the following would still be quite valuable:

• A set of CLI commands which do everything except install.ps1; when they see that a package has that they fail predictably with an unsupported error message.
• Building on the former, have the commands support install.ps1 passing in stub objects which support the most commonly-used operations and fail predictably otherwise.

I'm glad that work is being put into dotnet.exe but my understanding is that this won't support .NET framework apps (as opposed to .NET core), will require the new VS2017 project file format, etc. (please correct me if I'm wrong). These limitations will limit our ability to take advantage of that tool for quite a long time.

FWIW, in general I think NuGet would be in a better place if it was less tightly-coupled to Visual Studio and dotnet.exe.

[rrelyea]

Thanks for the feedback.
We will put this in our backlog. As we continue to invest in better CLI commands, it will help us understand customer needs.

[sanderaernouts]

+1

I'm in a similar situation as @madelson, furthermore it is not possible to upgrade all projects to the new CSPROJ format yet so we have to use the old format in some places for a while (for example in WPF projects). Access to the project should not be that hard, I'm actually using the Microsoft.Build package myself to validate the old .csproj files in a certain solution against the packages.config files after updating because we have seen a lot off issues with duplicate imports of props and targets files, hintpaths not being updated, etc.

Nuget.exe update should do what Update-Package does, nuget.exe install should do what Install-Packages does, etc. The way it is right now the nuget.exe CLI is useless to me. The only somewhat workable alternative is running a Powershell script from within the Package Manager Console inside Visual Studio.

[emgarten]

We investigated providing full command line support for packages.config on the command line, the result of that work is PackageReference. With PackageReference nuget no longer calls into the VS project system, it instead writes everything out to project.assets.json and build consumes this directly.

[madelson]

@emgarten are you referring to the new VS2017 project file format?

[emgarten]

You can use the VS2017 NETCore SDK project style, or you can add PackageReference items to non-NETCore SDK projects also. PackageReference works all over with VS 2017 tools.

[madelson]

@emgarten can you point me to documentation on using PackageReference without the new project style?

[emgarten]

Sure! Take a look at https://blog.nuget.org/20170316/NuGet-now-fully-integrated-into-MSBuild.html

I would also make sure you are on VS 15.5, the latest version which has a lot of fixes in this area over the original 15.0 release.

[rahulkulkarni40]

Hello @emgarten ,
I have created an MSI file with nuget live graph . Does that MSI works on Windos 7 OS and does live chart created Works on Windows 7 OS please help me out

[skolod]

I cannot update from Nant build script NuGet package that is referenced directly from CsProj via ProjectReference element, while I can do it from VS, because VS launches NuGet Package Manager before MsBuild. I choosed PackageReference format because it allows me to write a floating version of package (1.8.0-beta*). I think it is not right that I cannot reproduce VS build process in command line.
I have VS 2017 15.6 installed.
The problem is solved when I added /r option to MsBuild command.