2

First, I will describe our setup (it is an extremely simplified version of the corporate development pipeline). We develop a .NET application, which is dependent on some shared components. The shared components typically develop together with the application. We want turn these shared component to NuGet packages.

So, I publish version 1.0.0.4 of package A and want to consume it in my application. My packages.config looks like this.

<package id="A" version="1.0.0.4"/>

So far so good. I probably commit packages.config to version control at this point to remember my dependencies. Now I run the next build of package A, which publishes the version 1.0.0.5. Now I want my application to automatically update package A to 1.0.0.5 before the build.

However, my packages config now contains an exact verion 1.0.0.4 and it's version-controlled. My questions are:

  • Can I somehow specify that I want version 1.0 or higher in packages config? In other words, can I avoid change of packages.config with every new build of every package?
  • Can I somehow update the dependencies before build to the the newest version? Can I do it automatically using a script?

I am quite new to NuGet and I come from the ant+ivy/maven world, where this feature is kinid of automatic, so I am still hoping I am missing something obvious in NuGet, although scanning through the discussions on stackoverflow doesn't sound too encouraging.

I've found Using Nuget in development environment - best practices / how to and How to automatically update NuGet packages to latest available version and NuGet issues with packages.config, project references and the solutionwide packages folder, which do not give clear answers.

Community
  • 1
  • 1
batusek
  • 123
  • 1
  • 7

2 Answers2

1

You can use the allowedVersions attribute to automatically use newer package versions within a range, like this:

<packages>
    <package id="SomePackage" version="2.1.0" allowedVersions="[2,3)" />
</packages>

In this example, any package from the 2.x series will be used, but not from the 3.x series. You can be more specific with the contraint e.g. `allowedVersions="[2.1,2.4)" if you wanted to take any package from 2.1, 2.2, and 2.3 but not 2.4.

See http://docs.nuget.org/docs/reference/versioning for more details

Matthew Skelton
  • 2,220
  • 21
  • 21
  • IMHO it is not possible. This link speaks about **nuspec** syntax _not_ about **packages.config** syntax. So the allowedVersions atribute is not allowed in packages.config. – batusek Feb 09 '14 at 09:05
  • 1
    It is definitely possible to specify `allowedVersions` in `packages.config`: "NuGet supports constraining the range of versions that packages can be upgraded to by hand editing the packages.config file using the allowedVersions attribute." http://docs.nuget.org/docs/reference/versioning#Constraining_Upgrades_To_Allowed_Versions I have been using this for 2+ years :) – Matthew Skelton Feb 09 '14 at 17:23
  • @MatthewSkelton could you give an example of what your packages.config and .csproj file looks like when consuming a package like this? I am trying to implement something very similar where we consume the nightly build of a NuGet package and have not been able to get it to work correctly. – jameswelle Mar 17 '14 at 17:33
0

I don't think you can change the packages.config to implicitly allow a higher version. Also, the project files have references to the packages folder which include the package version in the path, so those need to be changed after a package update.

You can perform an update of the packages.config and the projects files by running nuget update.

You could automate this in the nightly builds and checking in the resulting changes as well. However, it's debatable whether that's a good idea. At the minimum, you should gate the update operations by running a build to make sure the new version doesn't cause a build break.

Immo Landwerth
  • 3,239
  • 21
  • 22
  • We were inclined to do something like this. However, our packages are updated more often than once a day, so the update script would need to be run with every submit. I hoped there would be an easier solution. – batusek Feb 09 '14 at 09:10