You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
Sounds like what you need is assembly-version-format, similar to assembly-informational-format. It's starting to become rather messy with both assembly-versioning-scheme and assembly-file-versioning-scheme there already, though.
To get around the issue of assembly-informational-format missing the word version and being able to expand the formatting capability of all [Assembly*Version] attributes, perhaps we should mint an entirely new YAML key for this? Something like:
I think we could co-support the current functionality along with a new, much more flexible system based on format strings instead of enum values. The only enum value I would consider supporting is None, which as per #964 should mean the corresponding Assembly*Version attribute would not be emitted. Not sure that we can support both strings and enums simultaneously in the same key, though.
#886 might be talking about the same needs, but I'm unsure if they are fulfilled by #1130 or not. Either way, let's discuss how to solve this formatting requirement once and for all.
This issue has been automatically marked as stale because it has not had recent activity. After 30 days from now, it will be closed if no further activity occurs. Thank you for your contributions.
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 onCore
)Core.Data.Sql
(dependency onCore.Data
andCore
)We use the -IncludeReferencedProjects when building the NuGet packages, and commits are normally made against the
master
branch (with GitVersion configured formainline
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 onCore.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 thatCore.Data 4.0.8-branch.10
will be considered 'less' thanCore.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
(orNuGetVersionV2
) instead ofSemVer
.Is there any way to resolve this issue?
The text was updated successfully, but these errors were encountered: