This project is read-only.

How to handle versions for multiple packages that are interdependent

Feb 23, 2013 at 6:05 PM
Hi,

First this is an excellent project, please keep it going :D

So my scenario is this. We have one solution that builds 8 projects, which are 8 different components of the same framework. Starting with a common library, then there are 3 which are dependent on that, and then the further 4 are dependent on 1 or more of the others.

The problem is this... I can build and package them all seperately using the great new support for multiple packages, but I don't know how to handle version numbers in the dependencies.

During development changes to these libraries, we publish them to our nuget feed to allow related projects to test the changes. So when the build is initiated, we want to stamp them with the awesome versioning support you have with the current date and build number. This works brilliantly and as expected, however the nuspec files reference these other packages, and the version numbers in the dependency references does not get updated.

We handled this before (kind of, and before we were integrating this into tfs builds) by using the replacement tokens in the nuspec files, because all the version numbers stayed in sync. Therefore if we built the common library as version 1.0.0.1, we knew that the Extension1 library would also be 1.0.0.1, and that the version in the dependency reference (in the Extension1 nuspec file) could point to Common version 1.0.0.1.

Any ideas on how we could manage this with NuGetter, or just how we could perhaps change our process to avoid this issue?

Thanks for the great work. If you're ever in South Africa, feel free to hit me up for a Beer or two!

Adam.
Oct 9, 2013 at 11:31 PM
I've got the same scenario. Did you come up with a solution for this?
May 7, 2014 at 8:38 AM
I've also got the same scenario. Any solutions?
Jan 29, 2015 at 8:35 PM
I'm working through the issue now, but it appears that you can use the $version$ in the NuSpec file as a substitute for hard coding the value. I did specify the Version or Version Seed File Path as "1.0.J.B-dev" in the build definition, and used the following as a portion of my NuSpec file.
    <version>$version$</version>
    <dependencies>
        <dependency id="MyPackage.Core" version="$version$" />
    </dependencies>