NuGet versioning with gitflow

Question

Some background information to our actual situation. We are migrating from TFS VC to git. We've a ASP .NET Web API with many different Controller Libraries (>30 assemblies). Many of them are referencing some Core assemblies like our data model. In TFS VC those Core Assemblies where checked in relative to our projects in a binary folder. Not a best practice anyhow...

As we are moving to git we want to clean up this fault. Our idea is to share the Core assemblies as nuget package on a local Azure Dev Ops feed. We want to use git-flow workflow with branches: master, development and features/

Example

• CoreAssemblyA.csproj published to nuget feed with version 1.2
• ConsumerB.csproj - consuming CoreAssemlyA as a nuget package (current version 1.2).
• ConsumerC.csproj consuming CoreAssemblyA as a nuget package (current version 1.2).

Nuget package is packed and published during CI build and release pipeline within our AzureDevOps server after a pull request / merge commit.

Now there are two feature requests for ConsumerB and ConsumerC, handled by two independent developers, each require to change/extend the CoreAssemblyA.

1. Developer A: Starting with a feature branch: features/feature1. Extending code of CoreAssemblyA (eg. add properties to a class), change version to the next higher (starting from 1.2 => 1.3), start a pull request to development branch
2. Developer B: Starting at the same time with a feature branch: features/feature2. Extending code of CoreAssemblyA (eg. add properties to another class), change version to the next higher (starting from 1.2 => 1.3), start a pull request to development branch

---

Questions / ideas:

1. How to get rid of the version conflict they are running into? The second pull request and CI Build with a nuget push build task will fail with a "version already exists on feed"-error.

2. Another idea I thought about was to apply prerelease tags to the published nuget package. But if I reference CoreAssemblyA as a PackageReference with version: 1.3-* I'll get the version that is pushed last (either from developer A (feature1) or developer B (feature2)). To refernce the correct version in each feature branch the concrete prerelease version could be referenced in consuming csproj, but when and how to "cleanup" this version to get a non prerelease version into development during the pull request / merge commit?

3. A local package source or changing the .dll in nuget package folder seems to be a huge manual copy / paste overhead to me.

Maybe one can point me to the right direction.

Answer 1

By far the easiest way to handle this is to use a local package source.

If you make .net standard class libraries you can package them automatically after each build in VS. I guess you could automate further with a post build script.

Most people find the whole rigmarole of pushing, waiting for the build, pulling down the new nuget etc to the second project etc too much to bother with. Even without the added problems of prerelease builds named after feature branches etc.

Obviously we cant leave the subject without saying that "Core" assemblies are a code smell of the highest odour! Try to split them up and you won't have this kind of problem as much.

If you set the version to be 1.3.x.* and replace revision with the build number on your build server, visual studio will replace the * with seconds since midnight, January 1, 2000 when you do a local build. Usually leading to a larger number than the version built and published by the build server

Since you don't publish the locally built package, only the developer working on their feature branch will see it in their local package source. The version will be higher than the official build (due to the *), so they will be able to "upgrade" the package.

So in the source you control the major and minor build numbers, everyone gets the same and you only update them in develop at the start or end of a sprint.

You let the build set the build and revision parts of the version number, either via settings in your build server, or using the build in handling of the * wildcard