Extension Members: The Next Level of .NET API Design or Another Layer of Complexity?

Extension methods have long been a familiar way in C# to extend existing types without inheritance, source-code changes, or library recompilation. With .NET 10 and C# 14, this model evolves into Extension Members: extensions can now include not only methods, but also properties, static members, and operators.

At first glance, this makes APIs feel more natural: APIs defined outside a type can appear as part of that type’s own API. This enables member-like APIs for domain primitives, fluent APIs, and local DSLs. But this expressiveness also introduces a new layer of complexity: the compiler searches for extension members in the current context, and which member gets selected can depend on namespaces, using/global using directives, referenced packages, and overload resolution rules.

In this talk, we’ll look at how Extension Members work: the source syntax developers write, how the compiler finds suitable extensions, what ends up in metadata, and what is visible through reflection.

Using a running example, we’ll explore where Extension Members help build expressive APIs — and where they can start to hide important business logic. We’ll also discuss practical risks: ambiguous calls, changes in overload resolution after a package update, the impact of using/global using directives, semantic compatibility, and extension operators.