Home: Nuget update with PackageReference package management format not working

Created on 30 Oct 2017  路  6Comments  路  Source: NuGet/Home

Hi, I'm using the PackageReference package management format available in VS2017 rather than packages.config.

The Nuget restore command works fine, however, the Nuget update seems to be searching from projects that have a packages.config even though I'm explicitly providing the .sln file

The command I'm using is

\NuGet\4.0.0\x64\nuget.exe update "Test.sln"

The output I get is

Scanning for projects...
MSBuild auto-detection: using msbuild version '15.3.409.57025' from 'C:Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\bin'.
Found 0 projects with a packages.config file.

Does anyone know if this should work or some other way of forcing my packages to update?

Thank heaps.

NuGet.exe Question

Most helpful comment

I @emgarten I don't understand why this issue was closed when there was no solution or roadmap offered for resolution?

I'm aware of so many companies that have run into this issue in the real world. I'm wondering if the Nuget team have got there heads around it?

All 6 comments

NuGet.exe update does not support PackageReference.

I've opened https://github.com/NuGet/docs.microsoft.com-nuget/issues/542 to track improving the docs around this.

You can use floating versions to automatically update packages: https://docs.microsoft.com/en-us/nuget/consume-packages/package-references-in-project-files

For NETCore SDK projects you can use dotnet add to change the version of the PackageReference. You can also use MSBuild properties for the version and set the values of those dynamically.

Thanks @emgarten the problem with floating versions is that when developers add a package to a project or update the version of an existing project via Visual Studio, unless they remember to open the project file in notepad and apply a floating version it won't automatically be updated during the build process. Floating versions have to be manually applied.

This is quite a risky practice even with very careful and meticulous code reviews are performed.

Do you have any suggestions for handling this issue apart from reviewing all code changes for a change to packages?

This is quite a risky practice even with very careful and meticulous code reviews are performed.

What is the risk here over running a command to update the version? What would go wrong that wouldn't be immediately noticed?

As we currently run a Nuget Restore step prior to our solution build step, it makes sense to also run a Nuget Update step for the solution. This would update all packages for all projects associated with the solution based on the provided Feed url.

With the Nuget Restore step if a developer adds a package to a project the build will automatically restore and handle this change. No other manual intervention is required for this to work.

With the Nuget Update step, after the developer adds a package to a project, they must remember to open the csproj file in notepad and modify to a floating version. If they forget to do this, the build and subsequent release may pass. However, it may contain a version of the dependency other than the latest (the expected behaviour is for the release to contain the latest version of this package). This is quite risky.

Additionally if a developer opens the Manage Nuget packages dialog and updates to the latest version of a package, even if a floating version was configured for the package being updated, it will be overridden with a fixed version. Again, the developer may not be aware, or may forget they must then manually change this to a floating version in something like notepad before committing.

The ability to update all packages for all projects associated with the solution based on the provided Feed url (similar to the current behaviour of the Restore command) would solve all these process related risks.

I hope this provides a little more insight to the issue.

I @emgarten I don't understand why this issue was closed when there was no solution or roadmap offered for resolution?

I'm aware of so many companies that have run into this issue in the real world. I'm wondering if the Nuget team have got there heads around it?

NuGet.exe update does not support PackageReference. Use dotnet add to update the version from the command line, or supply the version from an MSBuild property.

For help with floating versions see https://docs.microsoft.com/en-us/nuget/consume-packages/package-references-in-project-files
Example: <PackageReference Include="NuGet.Versioning" Version="4.*" />

For general help on how to use NuGet please see the docs on https://docs.microsoft.com/en-us/nuget/ or ask for further help on https://stackoverflow.com/

If you are hitting a bug or have a specific feature request then please open an issue here on https://github.com/NuGet/Home/issues to track it.

Thanks!

Was this page helpful?
0 / 5 - 0 ratings