GitVersion Demo - C# Class Library with NuGet Packaging

This repository demonstrates how to use GitVersion to automatically version a C# NuGet package based on your git workflow, eliminating the need for manual version maintenance.

Overview

Instead of manually updating version numbers in your project files, GitVersion automatically calculates semantic versions based on:

• Branch names (main, develop, feature, release, hotfix, etc.)
• Git history and commits
• Configured versioning rules

Key Files

• gitversion.yml - GitVersion configuration defining version calculation rules for each branch
• Directory.Build.props - MSBuild property file that ensures all projects use GitVersion
• src/MyLibrary/MyLibrary.csproj - C# class library with GeneratePackageOnBuild: true
• azure-pipelines.yml - Azure DevOps pipeline showing automated versioning and packaging

Current Workflow

Your team currently:

1. Manually updates version numbers in project files
2. Builds and packages
3. Manages version numbers across multiple files

New Workflow with GitVersion

1. Push commits to branches following your branching strategy
2. GitVersion automatically calculates the version
3. Build and pack - version is automatically applied
4. NuGet package contains the correct version

How It Works

Configuration (gitversion.yml)

The configuration defines version bumping rules:

branches:
  main:           # Production releases - Patch version bumps
  develop:        # Main development - Minor version bumps
  feature/*:      # Feature branches - Minor increments until merged
  release/*:      # Release branches - Patch increments
  hotfix/*:       # Hotfixes - Patch version bumps

Version Propagation (Directory.Build.props)

The Directory.Build.props file:

1. Adds the GitVersion.MsBuild NuGet package to all projects
2. Automatically calculates version during the build
3. Applies the version to assembly and package metadata

Package Generation (.csproj)

<GeneratePackageOnBuild>true</GeneratePackageOnBuild>

This setting ensures:

• NuGet package is created on every build
• Package version matches what GitVersion calculated
• No manual version management needed

Getting Started

Prerequisites

• .NET 9 SDK (or whichever version is installed)
• GitVersion (installed via azure-pipelines.yml or locally via dotnet tool install -g GitVersion.Tool)

Build Locally

# Install GitVersion tool (one-time)
dotnet tool install -g GitVersion.Tool

# Build the library
dotnet build src/MyLibrary/MyLibrary.csproj --configuration Release

# Alternative: Use msbuild directly
msbuild src/MyLibrary/MyLibrary.csproj -p:Configuration=Release

# View generated NuGet package
ls bin/Release/*.nupkg

Run on Azure DevOps

1. Create a new repository in Azure DevOps
2. Push this code to the repository
3. Create a pipeline from azure-pipelines.yml
4. The pipeline will:
   • Calculate the version using GitVersion
   • Build the project
   • Generate the NuGet package with correct version
   • Publish as an artifact

Branching Strategy

This demo uses Git Flow with these branch patterns:

Branch	Version Bump	Use Case
main	Patch (1.0.0 → 1.0.1)	Production releases
develop	Minor (1.0.0 → 1.1.0)	Integration branch
feature/*	Pre-release on develop merge	New features
release/*	Patch from Release	Release candidates
hotfix/*	Patch from Main	Critical fixes

Example Workflow

Starting Point: v1.0.0

# Create a tag for the initial release
git tag v1.0.0
git push origin v1.0.0

Adding a Feature

# On develop branch
git checkout develop
git checkout -b feature/add-division

# Make changes...

git commit -m "Add division method to calculator"
git push origin feature/add-division

# PR → Merge to develop
# Result: v1.1.0-rc.1 (Release Candidate)
# After merge: v1.1.0-prerelease.1

Creating a Release

git checkout release/1.1.0
git commit -m "Bump version for release"
git push origin release/1.1.0

# Result: v1.1.0-rc.X
# After merge to main: v1.1.0 ✓

Hotfix for Production

git checkout -b hotfix/critical-bug
# Make fix...
git commit -m "Fix critical calculation bug"

# Merge to main
# Result: v1.0.1 (Patch bump)

# Also merge back to develop to keep in sync

Version Information Available During Build

GitVersion exposes many variables for use in your build process:

GitVersion.SemVer         = 1.2.3
GitVersion.MajorMinorPatch = 1.2.3
GitVersion.Major          = 1
GitVersion.Minor          = 2
GitVersion.Patch          = 3
GitVersion.PreReleaseTag  = (empty if not pre-release)
GitVersion.FullBuildMetaData = ... (full metadata)

Verification

After building, check the generated NuGet package:

# Open package with NuGet Package Explorer or:
unzip bin/Release/MyLibrary.*.nupkg -d temp-package
cat temp-package/.nuspec

The .nuspec file will show:

<version>1.2.3</version>  <!-- Automatically set by GitVersion -->

For Your Demo Audience

Key Points to Emphasize

1. No More Manual Versioning: Version is derived from git history automatically
2. Consistent Versioning: Same version calculation across local, CI/CD, and production
3. Semantic Versioning: Automatically follows SemVer standards (Major.Minor.Patch)
4. Branch-Based Bumping: Different branches trigger different version increments
5. Reproducible Builds: Same commit = same version, every time

Before vs After

Before (Manual):

• Developer manually edits MyLibrary.csproj → version="1.2.3"
• Easy to forget updating
• Risk of version mismatches in CI/CD
• Multiple files to maintain

After (GitVersion):

• Commit to branch → GitVersion calculates version → Build uses that version
• No manual updates needed
• Consistent across all builds
• Single configuration in gitversion.yml

Resources

• GitVersion Documentation
• Azure Pipelines GitVersion Task
• Semantic Versioning
• GitHub Flow Alternative