C# Programming Language Articles

C# is Microsoft’s modern, statically-typed language for .NET development. This collection explores C# features, language evolution, practical patterns, and techniques for writing clear, efficient code in the C# ecosystem.

Language Evolution and Features

C# has evolved significantly since its creation, adopting features from other languages and innovating independently. Modern C# (10+) includes records for immutable types, nullable reference types for null-safety, pattern matching for elegant code flow, and async/await for asynchronous programming.

Records provide concise syntax for immutable data types with structural equality, ideal for domain models and data transfer objects.

Nullable Reference Types make null-safety explicit at compile time, preventing the infamous “billion-dollar mistake” of null reference exceptions.

Pattern Matching enables elegant code for type checking, null checking, and property matching without verbose if-else chains.

Async/Await abstracts the complexity of asynchronous programming, enabling responsive applications without callback hell.

Practical C# Development

Articles in this section cover language features, effective C# patterns, performance optimization, LINQ mastery, and integration with .NET libraries. Topics include null handling strategies, immutability patterns, error handling approaches, and leveraging type system features.

The goal is writing C# code that’s not just correct but also expressive, maintainable, and performant—code that communicates intent clearly and resists bugs through type safety and language features.

C# 15 Union Types and Closed Hierarchies in Preview

C# 15 preview ships union types with real compiler-checked exhaustiveness, no more hand-rolled sealed hierarchies for a Result type. The catch: it is a union of pre-existing types, not F#-style discriminated cases, and value-type cases box unless you write non-boxing boilerplate yourself. The quieter sibling feature, closed hierarchies, may be the safer bet for enterprise teams right now.

My Analyzer Shipped Without Checking Its Own Source

NetEvolve.Analyzer enforces null-check idioms and file organization on other people’s code, but had never run against its own. Fixing that surfaced 39 warnings, a silent Visual Studio MEF failure, and a follow-up NE0008 bug where DateOnly and TimeOnly got flagged blind to which target framework actually has them, the same multi-targeting blindness in a different corner of the codebase.

Incremental Source Generators Done Right: Ship It Without Breaking Consumers

Packaging Generators

Parts 1 through 3 of this series made the generator correct, incremental, and proven by tests. None of it reaches a single consumer if the NuGet package is laid out wrong — and the failure modes are silent: a DLL in lib/ instead of analyzers/dotnet/cs simply never loads, a missing dependency throws only inside the compiler, and a marker attribute delivered carelessly breaks InternalsVisibleTo in ways users cannot diagnose. This final part covers the packaging contract: the netstandard2.0 rule, the package layout, dependency bundling, attribute delivery, debugging the shipped bits, and the analyzer hygiene rules that keep you honest.

Prove the Cache Hits

You followed the equality rules, you shaped the pipeline correctly, and your generator still might be re-running on every keystroke — because nobody ever asked the driver. Roslyn records exactly why each pipeline step re-executed, and you can assert against those reasons in a plain xUnit test. This is the test that turns “my generator is incremental” from a claim into a regression-protected fact, plus the catalog of anti-patterns it catches in the wild.

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.