Using Source Generators to Cut Boilerplate in .NET Projects

Every C# developer has stared at a class file filled with repetitive property declarations, equality checks, or constructor glue that adds nothing meaningful to the actual business logic. These blocks of code, often called boilerplate, have haunted .NET projects since the earliest days of the framework. They appear in DTOs, in MVVM view models, in logging wrappers, and in dependency injection registrations, slowly turning clean architectures into forests of sameness. For years the answer has been reflection, code snippets, or T4 scripts, each with its own limitations. The arrival of Roslyn-powered source generators shifts that answer in a much more interesting direction.

Source generators are a compile-time metaprogramming feature that arrived with .NET 5 and matured across later releases. They run inside the build pipeline, inspect user code or external metadata, and emit extra C# files that the C# compiler merges into the final assembly. Because the work happens before runtime, the generated code behaves like hand-written code: it is fully debuggable, it benefits from IntelliSense, and it ships with zero allocation cost. The move from reflection-driven libraries toward generator-driven ones is one of the quietly significant shifts in the modern .NET ecosystem, and developers in Sydney, Melbourne, and Brisbane are starting to take notice.

For those who want a deeper dive into the practical side of tooling and automation, the C# Corner Annual Conference has a packed agenda covering compile-time productivity, code quality, and related topics.

What Source Generators Actually Do

At their core, source generators are small .NET programs that hook into the Roslyn compiler pipeline. A generator implements either the older ISourceGenerator interface or, more commonly today, IIncrementalGenerator. Both expose a Register method, but the incremental variant lets the generator cache work between compilations, which keeps build times sensible even on large solutions. When the compiler starts up, it loads every registered generator, gives it access to the current Compilation, the set of SyntaxTrees, and any additional AdditionalText files or metadata the project supplies.

A generator walks those syntax trees, looks for patterns that match its trigger — usually a custom attribute, a base class, or a particular interface implementation — and produces one or more strings of C#. The Roslyn code wraps the string in a SourceText instance, returns it from Register initialization, and the compiler writes it to the obj directory before the next compilation pass. The resulting files become first-class members of the project. They participate in semantic analysis, they show up in dotnet test output, and they can be inspected with the standard debugger.

The key conceptual shift is that source generators are not runtime libraries. There is no reflection at app startup, no Assembly.LoadFrom trickery, no dynamic proxy. The generated code is part of the assembly at build time, so trimming, AOT, and single-file publishing all behave the way you would expect. For teams shipping to constrained environments — common in Perth's mining sector where edge devices run trimmed binaries — that difference matters a lot.

Targets Worth Automating in Real Codebases

Once a team starts looking for boilerplate, it usually finds more than it expected. The most obvious targets are classes that implement INotifyPropertyChanged for WPF, .NET MAUI, or Avalonia view models. Manually written property notifications duplicate the property name, repeat null checks, and frequently introduce subtle bugs when a developer renames a field but forgets the backing notification. A source generator can scan partial properties, infer the type, and emit a fully wired-up OnPropertyChanged call automatically.

Equality and hashing are another classic case. For value-like records, the C# compiler already generates Equals, GetHashCode, and the == operator. For larger domain entities, however, the generated implementations often miss derived members or ignore collection fields. A generator that reads a [CompareBy] attribute and walks the chosen members can produce correct, allocation-free equality code on every build. The same pattern applies to ToString, which is rarely updated when new fields are added.

Logging, dependency injection, and interop wrappers are also ripe for automation. A generator can take a logger injected through constructor injection and produce strongly typed LogInformation, LogWarning, and LogError wrappers, sparing the developer from passing structured state names by hand. Mapping between DTOs and domain entities, JSON converter registration, and OpenAPI schema emission all benefit from the same approach. Anywhere you find yourself writing the same code structure with different type arguments, there is a generator waiting to be written.

Anatomy of a Generator Project

Building a generator is much like building any other class library, with a few project properties tuned for the special role it occupies. The project targets netstandard2.0 so it can run on whatever compiler version the consumer uses, and it references the Microsoft.CodeAnalysis.CSharp package along with Microsoft.CodeAnalysis.Analyzers for diagnostic hygiene. Inside the project, the generator class is decorated with [Generator] from the Microsoft.CodeAnalysis namespace, and it implements IIncrementalGenerator.

Once the project compiles, the consumer references it through an <Analyzer Include="..." /> MSBuild entry rather than a normal <ProjectReference>. From that point on, every build of the consumer project loads the generator, asks it for source, and merges the result. To peek at what the generator actually produces, set <EmitCompilerGeneratedFiles>true</EmitCompilerGeneratedFiles> in the consumer's .csproj and look inside the obj/GeneratedFiles/ folder. Generated files keep their .cs extension and are easy to diff during code review.

Debugging follows the standard Roslyn analyzer model. Setting <DebugType>portable</DebugType> on the generator project and attaching to the consumer's dotnet build process lets developers step through the generation code in Visual Studio or Rider. Teams in Melbourne have even been known to settle into a quiet café in Carlton or Fitzroy for a few hours of generator debugging between sittings of the local .NET user group meetup.

Incremental Generation and Build Performance

The shift from ISourceGenerator to IIncrementalGenerator is the single most important performance change in the modern source generator story. The incremental model treats every piece of input as a value provider that can be cached and reused. If only one file changes, Roslyn only re-runs the providers whose inputs actually changed, and unchanged providers return their previously computed output. For a large solution with dozens of partial classes, this is the difference between a four-second incremental rebuild and a forty-second one.

Incremental pipelines are built from three pieces: SyntaxProvider, which filters syntax nodes down to the ones the generator cares about; CompilationProvider, which gives the generator access to semantic models and types; and AdditionalTextsProvider, which exposes any external files the project ships. Combining these providers through Combine, SelectMany, and WithTrackingName produces a pipeline that scales linearly with the size of the change set rather than with the size of the entire codebase. Australian teams collaborating across AEST and AEDT with colleagues in Europe and North America find that this scalability is what makes generator adoption viable in continuous integration.

Patterns That Fit Australian Codebases

Commercial .NET teams across the country have started to settle on a few recurring patterns. In Sydney's CBD, fintech groups working with regulations from ASIC and APRA have replaced handwritten DTO equality with generators that read attributes and produce audited implementations, which keeps review code focused on policy. In Brisbane, the local Queensland .NET community has shared examples of generators that wrap NServiceBus handlers, eliminating repetitive unit-of-work scaffolding. Perth-based teams supporting the resources sector often run generators that produce strongly typed wrappers around long-running mining telemetry streams, keeping Kafka-style interfaces in tidy compiled form.

Across these teams, a few habits seem to repeat. Generators tend to grow from a single attribute or partial class marker, so adoption stays optional. Output is usually routed into a single Generated/ namespace with a stable prefix, which keeps the diff easy to scan during pull requests. When something does break, the typical response is calm and pragmatic: fix the generator, ship a patch version, document the change clearly, and keep the door open for the consumer.

Common Pitfalls and How to Dodge Them

Source generators are powerful, but they come with a few traps. The first is naming collisions: if two generators emit a type with the same fully qualified name, the build fails in a way that is often confusing. Giving every generator a unique namespace and prefixing emitted types with a short company-specific tag, such as the team's three-letter handle, removes the confusion. The second is debugging. Even though generated files are visible inside the obj directory, stepping into them requires a debugger attached to the compiler process. Setting up that debugging loop early saves hours later.

The third trap is interaction with nullable reference types and trimming. Generated code must respect the project's nullable annotations and must not introduce types that disappear under PublishTrimmed. Writing generators against the Roslyn rewriter-aware APIs rather than hand-rolled string concatenation sidesteps most of those concerns. Finally, keep in mind that not every runtime library benefits from being rewritten as a generator. Libraries whose behaviour depends on configuration that is only known at runtime — for example, plug-in loaders — still need reflection. The goal is to remove boilerplate where the structure is fixed, not to eliminate every dynamic path.

Building Your First One and Learning More

A good first generator is small in scope. Pick a class that implements INotifyPropertyChanged, mark it with a custom attribute, and write a generator that emits a partial implementation with the backing SetProperty calls. Add a few properties, run the build with EmitCompilerGeneratedFiles enabled, and inspect what came out. From there, expand to equality, then logging, then DI module generation.

After the basics feel comfortable, look at well-known open-source generators for inspiration. Libraries such as Microsoft.Extensions.Logging.Generators, the source-generated JSON support inside System.Text.Json, and the CommunityToolkit.MvVM package all show how production teams structure their generators and how they document the generated surface area. Reading their code is the fastest way to internalise the patterns, especially the way they keep the public API stable while the internal generator evolves.

For developers who want to see generator code live and ask questions of the people building these tools, conference sessions on Roslyn and developer productivity are a natural next step. A multi-day agenda makes it easy to find a track that matches your level, whether you are new to metaprogramming or already shipping internal generators to hundreds of services.