Description
We have a .NET solution that contains many common libraries used across our other products. The projects tend to build on each other, extending functionality to more specific (but still common) purposes - for example, We have:
Core
Core.Data
(dependency on Core
)
Core.Data.Sql
(dependency on Core.Data
and Core
)
We use the -IncludeReferencedProjects when building the NuGet packages, and commits are normally made against the master
branch (with GitVersion configured for mainline
development).
We've recently had to cut a branch for some development, and we are noticing that the NuGet package has a dependency referencing the assembly version, not the nuget package version, so we are unable to update them in the upstream solutions.
For example, Core.Data.Sql 4.0.8-branch0004
has a dependency on Core.Data 4.0.8-branch.4
(which doesn't exist - Core.Data 4.0.8-branch0004
does). We could update the nuget version on pack to be the SemVer version, but my understanding is that Core.Data 4.0.8-branch.10
will be considered 'less' than Core.Data 4.0.8-branch.9
(when in fact it's greater).
It looks like when we patch the assembly version with GitVersion we don't have control over which of the calculated versions should be used. In this case, it would be nice to be able to change the version to use NuGetVersion
(or NuGetVersionV2
) instead of SemVer
.
Is there any way to resolve this issue?