C# Source Generators: Patterns & Build Costs

C# Source Generators are a Roslyn compiler feature introduced in .NET 5 that produce code at build time and inject it directly into the compilation pipeline. They eliminate runtime reflection, replace hand-written boilerplate with generated equivalents, and unlock metaprogramming patterns that previously required IL weaving or T4 templates. The cost — and most getting-started guides skip this part — is that every generator runs on every build, on every target framework, and inside the IDE while you type.

Add a single NuGet package that ships a source generator and a 2-second build can quietly become an 8-second build. Multiply that by every team member, every CI run, every Hot Reload cycle, and the tax accumulates fast. The package description rarely mentions it. The damage is real but not advertised.

The articles in this collection cover what source generators actually do under the hood. The incremental generator API exists specifically to reduce repeated work between builds, but only generators written carefully against the IIncrementalGenerator interface benefit from it — many published packages still use the older ISourceGenerator model that rebuilds everything on every keystroke. Measuring the cost requires binary logs and the right MSBuild diagnostic flags rather than guesswork.

Pragmatic patterns get specific attention. When generators are worth the cost — eliminating reflection in JSON serialization, building strongly typed configuration accessors, generating regex code that JITs faster than Regex.Compiled — the trade-off makes sense. When they are not — generating one-off helpers that could be a static method, replacing five lines of obvious code with a complex generator pipeline — the tax is pure overhead.

The collection also addresses the IntelliSense and Hot Reload regressions that compound across solutions with several generators stacked together, and the diagnostic techniques required to identify which generator is the actual culprit.

Pipeline Patterns

Part 1 of this series established the equality contract: every value flowing through an incremental generator pipeline must be comparable by value, or the cache misses and the generator re-runs on every keystroke. This part is about the pipeline itself — ForAttributeWithMetadataName as the entry point, where to filter, where to transform, how to combine providers without accidentally subscribing to the entire Compilation, and the Collect trap that silently breaks everything you fixed in part 1. It ends with a complete worked generator you can steal.

The Equality Contract

IIncrementalGenerator exists for one reason: to run only when its inputs actually change. Most generators fail at exactly that, because somewhere in the pipeline a value is compared by reference and the cache silently misses. This is part 1 of a 4-part series on getting incrementalism right, and it starts where every broken generator starts: the equality contract, the ImmutableArray trap, and the EquatableArray that fixes it.

TUnit.Mocks: No Castle, No Reflection, No Drama

Most .NET test projects rely on NSubstitute and Castle.DynamicProxy. That foundation is cracking: NativeAOT breaks it, trimming strips it, cold-start costs accumulate. TUnit.Mocks takes a different route: a source generator emits typed mocks at compile time, IService.Mock() (or Mock.Of<T>()) is the entry point, runtime reflection is gone.

Source Generators: The Build Performance Killer

Source Generator Costs

Source generators are powerful. They are also running on every single build, blocking IntelliSense, breaking Hot Reload, and multiplying their cost across every target framework you support. Nobody mentions this in the getting started guides. Here is how to measure the damage, find the culprits, and decide when source generators are actually worth it.