nuget.exe 2.7.1 version number stale?

Topics: General
Nov 7, 2013 at 4:13 PM
I downloaded nuget.exe from under 2.7.1 release heading and both the unsigned and signed files have the file version of 2.7.40906.213 and product version of 2.7.0.
And even though one says signed build and the other doesn't, both seem to be signed?
Nov 8, 2013 at 4:18 PM
I am a little confounded with all these different versions of nuget.exe 2.7 line.

When I install NuGet.CommandLine tool via package manager console, I get 2.7.40906.75.
When I download from this website's download page under 2.7.1 heading, I get 2.7.40906.213.
Both have the product version 2.7.0 - I don't know, maybe that's how you guys operate but to me, it seems that it should say 2.7.1.

Furthermore, in my own project using these two different versions, I find that revision 213 does not handle IncludeReferencedProjects option correctly in that when the referenced project does not have a .nuspec along the .csproj, the output assembly should be included as part of the referencing project's package, inside lib folder. But revision 213 does not do this. Revision 75 does.
I also downloaded the source by goint to Source Code page and selecting 2.7 in "Browsing changes in" dropdown, which has 2.7.1 next to it with yellow highlight and the commit cfe62a2e8bb5 (excuse my ignorance if any, I'm no git user) and built locally to test and IncludeReferencedProjects work as well.

I will log this as a defect as well so that it's tracked.

Can someone sort out these versioning problems?
Nov 8, 2013 at 9:19 PM
IncludeReferencedProjects option does work indeed.

What I was doing was in my MSBuild script, pack with IncludeReferencedProjects and immediately followed by pack with Symbols.
Unbeknownst to me, what that was doing was the first pack will correctly generate the package with referenced projects but the second pack (with symbols) basically overwrites the original package without the referenced projects, then writes the symbols package.

Looking at the source, it's because symbols option works as an additional work completly distinct from the original package. So it generates a regular package and then if Symbols option is specified it generates the symbols package alongside the binary package.

I worked around by first generating the symbols package then generating the binary package.

It seems that it would be possible to generate only the symbols package without first writing the binary package. I don't know why it's being done this way.
Better yet, the issue where specifying both IncludeReferencedProjects and Symbols option should be fixed and we wouldn't have this problem from the get-go.