Bennewitz.Ninja.AutoVersioning 2026.3.916

Bennewitz.Ninja.AutoVersioning

A Roslyn incremental source generator that injects assembly metadata attributes and build-time constants into .NET projects at compile time — no AssemblyInfo.cs, no disk writes, full IDE caching.

Requirements

.NET SDK 6.0 or later (requires Roslyn 4.0+ for IIncrementalGenerator support). The consuming project may target any framework — .NET Framework 4.x, .NET Standard, .NET 6+, etc.

Quick Start

1. Add the package:

<PackageReference Include="Bennewitz.Ninja.AutoVersioning" Version="x.x.x" />

2. Enable the generator in your root Directory.Build.props (or any .props / .csproj imported by your build):

<PropertyGroup>
  <GenerateAutoVersionedAssemblyInfo>true</GenerateAutoVersionedAssemblyInfo>
  <AssemblyCompany>YourCompany</AssemblyCompany>
  <AssemblyProduct>YourProduct</AssemblyProduct>

  
  <CommitSha Condition="'$(CommitSha)' == ''">$(GITHUB_SHA)</CommitSha>
  <PublicVersion Condition="'$(PublicVersion)' == ''">$(MY_VERSION_VAR)</PublicVersion>
</PropertyGroup>

Note: The package's auto-imported Build.targets suppresses the 8 SDK-generated attributes that this generator also emits (e.g. AssemblyVersion, AssemblyCopyright), so you do not need to disable anything yourself. Do not add <GenerateAssemblyInfo>false</GenerateAssemblyInfo>: it is redundant, and broader than intended — that switch disables every SDK-generated attribute, including InternalsVisibleTo declared via MSBuild <InternalsVisibleTo> items. (A hand-written InternalsVisibleTo in a compiled .cs file is unaffected either way.)

A ready-to-use template is available at Directory.Build.props.template.

3. Build. The generator runs automatically — no further setup needed.

Tip: View the generated files in your IDE under Dependencies → Analyzers → *SourceGenerators.

Generated Output

Given a build on 2026-04-29 at 14:35 UTC for company Acme Corp, product Acme App, commit abc1234def, and public version 3.1.0:

AutoVersionedAssemblyInfo.g.cs

using System.Reflection;
using System.Runtime.CompilerServices;

[assembly: AssemblyDescription("Assembly Version: 2026.2.429.1435")]
[assembly: AssemblyConfiguration("Release")]
[assembly: AssemblyCompany("Acme Corp")]
[assembly: AssemblyProduct("Acme App v2026.2.429.1435")]
[assembly: AssemblyCopyright("Copyright 2026 [Release]")]
[assembly: AssemblyVersion("2026.2.429.1435")]
[assembly: AssemblyFileVersion("2026.2.429.1435")]
[assembly: AssemblyInformationalVersion("Commit♥: abc1234def")]
[assembly: AssemblyMetadata("CommitSha", "abc1234def")]
[assembly: AssemblyMetadata("GITHUB_SHA", "abc1234def")]
[assembly: AssemblyMetadata("PublicVersion", "3.1.0")]

DirectoryBuildInfo.g.cs

// <auto-generated/>
namespace Bennewitz.Ninja.AutoVersioning
{
    /// <summary>Build-time constants generated by the source generator.</summary>
    public static class DirectoryBuildInfo
    {
        public const string BuildRelease = "Version 2026.2.429.1435 [built 4/29/2026 2:35:00 PM (UTC)]";
    }
}

Use DirectoryBuildInfo.BuildRelease wherever you need the build version at runtime — error trackers, log enrichment, health endpoints — without reading environment variables.

Configuration Reference

Using the version from MSBuild

The generator calculates the version inside the Roslyn pipeline, which is too late for anything MSBuild decides. PackageVersion is the common casualty: it is evaluated long before compilation, so a library packs as NuGet's default 1.0.0 while the assembly inside that package is stamped 2026.3.913.1613. The package and its own contents disagree, and nothing reports it.

AutoVersion and AutoPackageVersion are derived during property evaluation from the same BuildTimestamp the generator is handed, so they are available early enough to assign:

<PropertyGroup>
  <PackageVersion>$(AutoPackageVersion)</PackageVersion>
</PropertyGroup>

Neither property is assigned to anything automatically — opting in is explicit, because this package should not quietly take over PackageVersion for every project that references it.

Three-part for packages on purpose: four-part versions are not SemVer, which matters for anything published publicly, and Pack.ps1 already defaults to that form.

GenerateAutoVersionedAssemblyInfo may be set anywhere the build sees it — Directory.Build.props, another .props file, or the .csproj itself. The SDK attribute suppressions live in the package's auto-imported Build.targets, which NuGet imports after the project body, so the flag is honoured regardless of where it is declared.

CI Provider Mappings

Map CommitSha from whichever variable your provider sets. The CI-flag column is listed for convenience only — this package does not read it; it is what you would condition your own MSBuild targets on (e.g. Condition="'$(GITHUB_ACTIONS)' == 'true'").

Version Format

The generator uses CalVer: YEAR.QUARTER.MMDD.HHmm

How It Works

This is a modern C# IIncrementalGenerator. Compared to legacy ISourceGenerator approaches it:

• Runs entirely in-memory — zero files written to disk
• Uses the Roslyn caching pipeline — the IDE (Rider, Visual Studio) only re-runs the generator when its inputs change, eliminating background compilation loops
• Reads MSBuild properties via AnalyzerConfigOptionsProvider — safe, no direct environment variable reads

The package auto-imports two files via NuGet: Build.props, which declares the CompilerVisibleProperty items and derives AutoVersion / AutoPackageVersion, and Build.targets, which suppresses the SDK's conflicting AssemblyInfo attributes (preventing CS0579 duplicate attribute errors when the generator is enabled). The suppressions live in the .targets because NuGet imports it after the consuming project's body, so GenerateAutoVersionedAssemblyInfo is honoured wherever it is set.

Timestamp Consistency in Multi-Project Builds

BuildTimestamp keeps the version consistent across every project in a solution build. See docs/MultiProjectBuildTimestamps.md for how it works and what alternative approaches were considered.

TL;DR: For CI, or any local build where an exact guarantee matters more than convenience, use -p:BuildTimestamp=... to fix the value explicitly instead of relying on evaluation-time capture. Ready-to-use wrappers are available at Build.ps1.template (Windows/PowerShell 7+) and Build.sh.template (Linux/macOS/bash).

Diagnostics

Building Locally

Requires PowerShell 7+ and the .NET SDK.

./Pack.ps1

The script prompts for a version (defaults to CalVer YYYY.Q.MMDD) and produces .nupkg files in packages/Debug/ and packages/Release/.

License

MIT © 2026 Brian Bennewitz