paket pack ignores specific-version parameter when inserting dependencies making created packages unusable

[mlidbom]

Say I have a solution with 3 packages that are packed using specific-version for each package.
A (AssemblyVersion: 3.3.0.0, specific-version: 3.3.0-beta01)
B (AssemblyVersion: 3.1.0.0, specific-version: 3.1.0-beta01, DependsOn: A)
C (AssemblyVersion: 3.5.0.0, specific-version: 3.5.0-beta01, DependsOn: A)

In the created packages the dependency on A in B and C are wrong. They both specify the version: 3.3.0.0 for A instead of the correct 3.3.0-beta01

[forki]

/cc @eiriktsarpalis
On Dec 20, 2015 9:04 AM, "Magnus Lidbom" [email protected] wrote:

Say I have a solution with 3 packages that are packed using
specific-version for each package.
A (AssemblyVersion: 3.3.0.0, specific-version: 3.3.0-beta01)
B (AssemblyVersion: 3.1.0.0, specific-version: 3.1.0-beta01, DependsOn: A)
C (AssemblyVersion: 3.5.0.0, specific-version: 3.5.0-beta01, DependsOn: A)

In the created packages the dependency on A in B and C are wrong. They
both specify the version: 3.3.0.0 for A instead of the correct 3.3.0-beta01

—
Reply to this email directly or view it on GitHub
#1321.

[eiriktsarpalis]

Hi, are templates you are creating of type project or file? I can't reproduce this error in my projects (which are of the former)

[eiriktsarpalis]

Hmm... Is your code available on github? Or could your provide a minimal repro?

[mlidbom]

The code is available, but anything but minimal :)
I created a branch to try and make it easy for you to have a look at it: https://github.com/mlidbom/Composable.Monolithic/tree/paket-pack-bug-repro

In the root folder you will find repro-paketpack-bug.ps1
If you are in powershell with the visual studio tools in your environment you can just run that file from the folder it is in. If not the code in it should make it easy to figure out what to to to make the repro.

Thanks for the quick response!

[eiriktsarpalis]

I think, and @forki correct me if I'm wrong in this, that inter-project dependencies need to be specified explicitly in your paket.template files. If Composable.CQRS depends on Composable.Core, you need to add a reference to Composable.CQRS with the CURRENTVERSION macro set.

[mlidbom]

If I don't use specific-version everything works correctly.

The documentation has this to say: https://fsprojects.github.io/Paket/template-files.html

This template file will create a nupkg: - Named Test.Paket.Package.[Version].nupkg - Version, Author and Description from assembly attributes - Containing $(OutDir)$(ProjectName).* (all files matching project name in the output directory) directory in the lib directory of the package. - Referencing all packages referenced by the project. - Package references - Project references, for projects in the sln that has paket.template files.

Note the last part:

Package references - Project references, for projects in the sln that has paket.template files.

[eiriktsarpalis]

I was not aware of this functionality. It might possibly be a later addition. It's clear that the specific-version implementation does not take this functionality into consideration.

[mlidbom]

Not easy to take something into account if you did not know it existed :)
Do you figure there will be a fix any time soon?

I'll take this opportunity to give everyone involved with paket a big high five. Everything seems so well thought out. Including specific-version. So far, whenever I think "I would like it to work like this" I just look in the docs and what I want is already there :)

After years of tearing my hair out in frustration with NuGet paket is here to save the day.
Big kudos to everyone involved in building this wonderful tool!

[inosik]

Try adding an the id parameter to your templates for now, even to the type project ones. There seems to be an issue with project dependencies if there is no explicit id.

I think we need to infer the id earlier, if it's not set explicitly in paket.template.

[mlidbom]

@inosik That did indeed make it work correctly. I newer would have guessed that would be a workaround! That will let me abandon my current workaround until we get a real fix. Thank you :)

@eiriktsarpalis Is that a real fix I spy there?

[eiriktsarpalis]

@mlidbom yeah, it fixes the issue at least in my reproduction of it.

[forki]

@eiriktsarpalis thanks for taking care of this

[mlidbom]

Hmm, I'm afraid that I still have the problem with 2.38.0.
Pull the latest from my repro branch(instructions above) to see the problem in action.

[eiriktsarpalis]

Did you try following @inosik's suggestion?

[mlidbom]

Yes. My development branch uses the workaround of specifying id manually, so there is no great hurry to fix this on my behalf :)

But it is still broken unless you manually specify id. Unless I'm missing something.

[mlidbom]

Eventually having this working will be kind of important to me though.
We will be migrating dozens of repositories to paket sometime reasonably soon.
Each of those creates a number of nuget packages and consumes many nuget packages created from the other repositories. In total I think we are talking around 100 different packages.

The simpler and the more standardized we can keep the template files the better. I would really like it if we can keep them all to a single identical line: type project

[eiriktsarpalis]

I'm not sure why this happens. @forki at what stage does the inference of project id occur?

[inosik]

It seems to occur when there is no id and no AssemblyInformationalVersion attribute. Paket then picks the version from the AssemblyVersion attribute, which doesn't allow prerelease information. This is what we see with @mlidbom's project.

I got a repro case here: repro.zip.txt. A and C depend on B.

1. Run FAKE with -ev OutputDir without-id
2. Remove the comment in B.csproj.paket.template
3. Run FAKE with -ev OutputDir with-id

Note that the CURRENTVERSION macro works as expected in both cases for A.

[forki]

@inosik I tried to run your example, but don't understand the issue yet.
What are you seeing after step 3 and what would you expect to happen instead?

[inosik]

The difference is in the unpacked C.nuspec. The resulting file after step nr. 1 contains

<dependencies>
  <dependency id="B" version="4.5.6.0" />
</dependencies>

while the file after step nr. 2 and 3 contains

<dependencies>
  <dependency id="B" version="4.5.6" />
</dependencies>

The version of the dependency doesn't come from the specific-version argument, but from the AssemblyVersion attribute in step nr. 1.

After steps nr. 2 and 3 C.nuspec should look the same.

[inosik]

Sorry, what I meant was, the version should be 4.5.6 in both cases.

[forki]

should be fixed now

[mlidbom]

I just tried this again on my repro branch and I can confirm that it seems to be working perfectly now.
Thank you both very much :)

[forki]

Awesome.