Home: Pack should re-evaluate project versions to allow git versioning

[AArnott]

Repro steps

1. Create two .netstandard libraries: A and B with a common solution directory.
2. Add the solution to git source control and commit.
3. Add reference from B to A
4. Install Nerdbank.GitVersioning package to both
5. Add a version.json file to the solution folder with content: { "version": "0.1-beta" }
6. Commit all changes to git.
7. Run a package restore on the solution and pack both projects.

Expected

The B nuget package references A package by its version (e.g. 0.1.2-beta)

Actual

The B nuget package references A package by a non-existent version 1.0.0

d15rtwsvc 26228.4

[AArnott]

This isn't something I can fix from Nerdbank.GitVersioning side because package imports are skipped when $(ExcludeRestorePackageImports)='true', which is set during restore operations. And the result of the restore seems to lock in the version of the package dependency that is used later when the referencing project is built.

So I'm reactivating this issue as a DCR for how or when P2P versions are established for purposes of inter-package dependencies.

[clairernovotny]

What if you set /p:ExcludeRestorePackageImports=false on the command line to override?

[AArnott]

@onovotny that may work as a workaround. I document another workaround on the NB.GV side that doesn't require the user to add this switch each time as well, but it's kinda ugly internally.

[AArnott]

But any workaround aside, this also means that when a commit is made, the next build will be broken because the package versions across P2Ps are locked in at restore time instead of at build time. IMO that's the fundamental issue here.

[clairernovotny]

@AArnott is there a link to the docs with the workaround? I just need to get Rx.net working right now... :/

[AArnott]

Yes: https://github.com/AArnott/Nerdbank.GitVersioning/issues/113

[clairernovotny]

Ping @unniravindranathan @rrelyea @morrisjoe

[bording]

I'd like to add my vote for this being an important scenario that needs to be supported without weird workarounds that function to various degrees.

It's a bit discouraging to see there's no one assigned and no milestone yet, which gives the impression that this is being ignored!

[dasMulli]

+1

Restoring with imported projects is dangerous as @emgarten mentioned in https://github.com/Microsoft/msbuild/issues/2080 because the 2nd restore may be affected by the first. Versions of project references should be able to flow to consuming projects on build/pack time.

[dazinator]

+1
Current Pack operation accepts a version argument at build time and then goes on to produce nuget packages with broken (invalid) dependency information for referenced projects..unless you have also discovered and added the secret sauce (doing a restore with the same version number prior.) which isn't intuitive from the pack API or clear from the docs on pack Api :-)

Probably worthwhile adding a mention of this process on the docs site

[AArnott]

All of you who are +1'ing this issue, I suggest you give a thumbs up to the issue itself so it's easier to track voting.

[rrelyea]

Thanks for the votes. Won't make 4.3 (VS 15.3) -- but will consider in future.

[clairernovotny]

Bump? How is this looking for 4.4? Would be really nice to get rid of a hack that requires additional imports due to $(ExcludeRestorePackageImports)='true'

[emgarten]

Using this issue to track all pack version/git versioning issues.

The current plan for this is to re-evaluate the project version at pack time. This will allow packages to modify the version used, and the version will not longer need to be set at restore time.

[erik-am]

This issue is biting my team as well... I hope a fix will make it in a next version of NuGet

[rohit21agrawal]

UPDATE : i will begin working on this in a week's time.

[clairernovotny]

@rohit21agrawal this may be related on a similar fix. The issue is that the pack targets are reading PackageReference info from the lock file instead of as msbuild items:
https://github.com/NuGet/Home/issues/6317

[rohit21agrawal]

FYI this fix is going to be release in Update 6 of Visual Studio aka 15.6

[NickCraver]

I'm hitting this on build servers now as well - which version of the SDK should we see it resolved in?