Home: Recommended way to update a package programmatically

[tomkuijsten]

We have a big repository which create lot's of nuget packages and we want to automate the update procedure of a nuget package. If our "release build" generated a nuget package, it should update all dependant projects which target an unstable package of that same released version. There are some options here, but none of those are a complete solution:

nuget.exe update

• Only updates csproj and packages.config, doesn't install (new) dependencies
• Doesn't support project.json

Update-Package

• Does the job, but only works in visual studio
• I don't want to use hacky ways like this)

Manual scripts

• We tried, but it's very complicated to get it right
• Especially new dependencies are difficult as it requires more then just altering reference paths or version numbers

How am I supposed to automate this update procedure?

[davidfowl]

It's pretty difficult with older nuget (the packages.config world) as you have to update both the packages.config and all of the hint paths. The newer (extremely new) project.json and PackageReference node are trivial to automate (it's basically text replacement in a file) with a script.

That said, nuget update should support all the supported formats eventually but for now your best bet is a custom script.

[emgarten]

+1 on moving to project.json or PackageReference, that is your best option for automating this scenario.

If you do need to stay with packages.config you could take a look at how NuGet automates running VS/NuGet commands from an external process as a starting point for your own scripts: https://github.com/NuGet/Entropy/blob/master/NuGetFunctionalTestsLauncher/NuGetFunctionalTestsLauncher/Program.cs

[tomkuijsten]

Since .NET 4.6.1 applications are not officially supported in the project.json/packagereference approach (not even in VS 2017 RC), we can't get rid of packages.config for a while. I know packagereferences for all project types is coming to nuget, there is just no timeline on when it will be available, and I need a solution now.

Thanks for your info @davidfowl and your pointers to code @emgarten . The only thing left for me to ask is... am I really the only one in the world with this problem? I feel kinda lonely in this area when I google for this problem, no one seems to have this issue. Which got me thinking... am I doing something really stupid here? Is it "not done" to automatically update packages, should it always be done manually? Since your both "Microsoft Insiders", you might be able to shed a light on "the right way" to update packages in a _continuous integration and delivery_ world.

[emgarten]

am I really the only one in the world with this problem?

We get asked this question often, you aren't alone :smile:

The solution to the problem is PackageReference and right now the team is dedicated to bringing it to as many project types as possible so you can move off packages.config.

[davidfowl]

am I really the only one in the world with this problem?

You aren't alone whatsoever. Today the ASP.NET team uses project.json and floating versions to constantly update to the latest versions of our dependencies. The .NET team have a script that bumps versions manually (they are also using project.json). It's pretty common, just a PITA with packages.config.

[tomkuijsten]

Thanks again for the clear statements, not feeling alone so much anymore 😀.

@davidfowl how does the .NET team use project.json, it's not supported for .NET classic projects right?

[tomkuijsten]

Just found this blog post explaining how project.json can be used with other project types, is that how the .NET team is using project.json as well?

[emgarten]

NuGet has been using it with .NET classic projects for a year now.
https://github.com/NuGet/NuGet.Client/blob/dev/src/NuGet.Clients/NuGet.VisualStudio/project.json

Roslyn is also: https://github.com/dotnet/roslyn/blob/master/src/EditorFeatures/CSharp/project.json

Take a look at this blog post for more guidance on it: https://oren.codes/2016/02/08/project-json-all-the-things/

[tomkuijsten]

Thanks for the links, really helpful. I'm convinced that moving to project.json would solve a lot of issues, but there are two things holding me back:

• The new PackageReference way is coming to all project types, if that's released soon, I'll rather wait for this official support
• I can't generate correct packages due to #3566 (which is not fixed in the latest 4.0 nuget)

What would you recommend in my situation?

[emgarten]

To use PackageReference with Visual Studio you will need 2017. It will not be supported in 2015, so that may help you decide which to use.

[bbowman]

@emgarten @davidfowl Any update on when this is coming to .vcxproj? As a related question, will PackageReference support the ability to use one nuget package's build injection when describing a second PackageReference? The crazy scenario I'm thinking about is using @kzu 's https://github.com/kzu/GitInfo/ to construct a package dependency version based on the current git tag to solve some local development / CI issues with picking up the latest package. @natemcmaster may be interested here too.

I'm guessing that my scenario won't work based on what I know about MSBuild but I'm also very curious how you guys are handling the injection of .props / .targets mid build.

[tomkuijsten]

@bbowman that's a different question, think it's best if you create a new issue for that to keep this thread on-topic

[tomkuijsten]

@emgarten that doesn't really help me, we have 2015 now, but tend to move to 2017 once it's released. This #3566 issue is holding me back right now.

[bbowman]

created https://github.com/NuGet/Home/issues/4119 so separate out the other question.

[zhili1208]

Project.json is dead, moving to package reference is the solution here. close it