DEV Community: Nikolay Pianikov

Pure.DI vs. Autofac: Code Generation or a Classic DI Container?

Nikolay Pianikov — Fri, 24 Jul 2026 12:10:01 +0000

Search the web for “a powerful DI container for .NET,” and Autofac will appear on almost every list. It has a well-earned reputation as a mature, feature-rich container: lifetime scopes, modules, decorators, keyed services, factories, Owned<T>, interception, and an extensible resolve pipeline.

Against this background, Pure.DI is sometimes perceived as a specialized generator that wins on speed but must fall behind a classic DI container in functionality. That comparison needs qualification: the libraries solve many of the same application-level problems, but they do so at different stages of the application lifecycle.

Pure.DI handles nearly the same everyday tasks as Autofac, but moves most of the container's work to compile time. From the setup, the generator builds an object graph—that is, a model of the dependencies—and uses it to generate code. The graph itself is a model, not a set of created instances. When the application accesses a root, the generated C# code creates the corresponding object composition.

Autofac stores registrations in a container and creates objects through the universal Resolve method at run time. Calling Resolve directly from application code can easily lead to the Service Locator anti-pattern.

Pure.DI works differently. It generates ordinary statically typed C# code and validates the dependency graph at compile time. Structural setup errors in the analyzed roots are therefore detected before the application starts. The public composition API consists of explicitly declared, strongly typed roots: properties or methods of that composition.

The comparison below uses Pure.DI 2.5.2 and Autofac 9.3.1. The Autofac examples come from its official documentation. The Pure.DI examples come from its documentation and test scenarios.

The Short Answer

When the application structure is known at compile time, Pure.DI covers the core Autofac feature set, detects structural errors in the statically analyzed graphs of declared roots, and eliminates the overhead of resolving dependencies through a classic DI container.

Autofac's main advantage appears when the dependency graph is determined at run time—for example, when plugins are loaded as assemblies while the application is running, registrations come from external configuration, or implementations are not known in advance.

When the priority is	Preferred option
A statically known graph, build-time validation, Native AOT, and minimal object-creation cost	Pure.DI
Plugins, dynamic registrations, and run-time resolve pipelines	Autofac
Ready-made multitenancy infrastructure and the extension ecosystem of a classic DI container	Autofac
Typed roots and readable object-creation code	Pure.DI

One Task, Two Architectures

A typical Autofac registration looks like this:

var builder = new ContainerBuilder();

builder.RegisterType<ConsoleLogger>()
    .As<ILogger>()
    .SingleInstance();

builder.RegisterType<OrderService>()
    .As<IOrderService>();

using var container = builder.Build();
var service = container.Resolve<IOrderService>();

At run time, Build() creates an Autofac container containing the registration descriptions. When Resolve<IOrderService>() is called, the container selects a constructor, locates dependencies, applies lifetime rules, and creates the object composition.

Source: Autofac registration concepts.

The equivalent Pure.DI setup is:

DI.Setup(nameof(Composition))
    .Bind<ILogger>().As(Lifetime.Singleton).To<ConsoleLogger>()
    .Bind<IOrderService>().To<OrderService>()
    .Root<IOrderService>("OrderService");

var composition = new Composition();
var service = composition.OrderService;

Source: injection of abstractions in Pure.DI.

Both snippets use the same domain types: ILogger, ConsoleLogger, IOrderService, and OrderService. The domain types are omitted because only the DI setup is being compared.

The setups look similar, but the approaches differ substantially. For the OrderService composition root, Pure.DI generates C# code for creating the object composition, conceptually similar to:

public IOrderService OrderService
{
    get
    {
        _singletonLogger ??= new ConsoleLogger();
        return new OrderService(_singletonLogger);
    }
}

Pure.DI does not search registrations or bindings at run time. The generator has already selected the types and constructors, and an error in the dependency graph becomes a compilation error rather than a run-time error.

Feature Matrix

Feature	Autofac	Pure.DI
Constructor injection	Yes	Yes, with compile-time validation
Property, field, and method injection	Yes for properties and methods	Yes for properties, fields, and methods
`Transient` and `Singleton`	Yes	Yes
Lifetime scopes and `Scoped`	Yes	Yes
Named and matching scopes	Yes	Separate and dependent compositions, `SetupScope`, tags
Delegates and factories	`Func<T>`, `Func<X, Y, T>`, custom delegate factories, lambda registrations	`Func<T>`, `Func<X, Y, T>`, factories with arguments, strongly typed root methods
Deferred creation	`Lazy<T>`	`Lazy<T>`
Collections of implementations	`IEnumerable<T>` and other relationship types	Arrays, lists, enumerables, dictionaries, and ranges
Named and keyed services	Names, keys, `IIndex<TKey,T>`	Tags, smart tags, `IReadOnlyDictionary<TKey, TValue>`, `IKeyedServiceProvider`
Generic bindings	Open generic type registrations	Precise generic bindings with marker types
Generic roots with type constraints	No dedicated API: the container resolves an already closed generic type	Yes; the root is generated as a generic C# method
Decorators	Built-in decorator registration	Ordinary bindings and tags processed at compile time
Interception	Integration with Castle DynamicProxy	Generated interception methods; Castle DynamicProxy when needed
`Owned<T>`	A separate lifetime scope	A separate ownership model for the object composition being created
Synchronous and asynchronous disposal	Yes	Yes
Building up an existing object	`InjectProperties()`	Properties, fields, and methods through `BuildUp`/`TryBuildUp`
Modules	Run-time modules	Dependent, internal, and global compositions
Assembly scanning	Yes, at run time	No: types must be known at compile time
Registration sources	Yes, registrations can be supplied dynamically	No direct equivalent: the graph is fixed at compile time
Resolve pipelines	Yes, middleware for services and registrations	No run-time pipeline; generated interception methods are available
Registration configuration	Modules and external run-time configuration	Setups are part of the source code and require recompilation
`Meta<T>` metadata	Yes, including strongly typed metadata	No direct `Meta<T>` equivalent; compile-time tags and attributes are available
Multitenant containers	Ready-made run-time infrastructure	No direct equivalent; compositions can be created for individual tenants
Pooled instances	Ready-made pooling package	No built-in lifetime; an object-pool example implements the pattern in application code
Compile-time validation of declared root graphs	No	Yes
Explicit typed roots	Not the primary model	Yes
Typed root arguments	No dedicated root API; `Resolve` parameters and delegate factories are available	Yes; roots are generated as ordinary methods
Native AOT	Supported with limitations	Generated object-creation code does not require .NET Reflection; see the Native AOT example
`Span<T>` and `ref struct` in the graph	Not available as universal relationship types	Yes
`ref` dependencies and stack-only root arguments	The container's universal object-based API cannot pass managed references or non-boxable `ref struct` values; external typed code is required	Yes, including generated root methods with `scoped ReadOnlySpan<T>`
Union types as DI contracts	No	Yes
Interface generation	No	Yes
Nullable annotations as part of a DI contract	`T` and `T?` are represented by the same `System.Type` and cannot be distinguished by `Resolve(Type)`	Yes, validated throughout the graph
Inspecting and debugging object-creation code	Internal run-time pipeline	Ordinary generated C#

The upper part of the table lists shared features, followed by Autofac features without a direct Pure.DI equivalent and Pure.DI features without a direct Autofac equivalent. Some rows describe different ways to solve the same application-level problem rather than direct counterparts. For example, an Autofac lifetime scope and a Pure.DI dependent composition have different semantics, although both help define boundaries for object creation and ownership.

Registrations, Lifetimes, and Implementation Selection

Lifetimes

Autofac supports the following instance scopes: Instance Per Dependency, Single Instance, Instance Per Lifetime Scope, Instance Per Matching Lifetime Scope, Instance Per Request, Instance Per Owned, and Thread Scope.

Source: Autofac instance scopes.

Pure.DI supports:

Transient: a new instance for each injection;
Singleton: one instance per composition;
Scoped: one instance per scope;
PerResolve: one instance per root construction;
PerBlock: reuse within a block of generated code.

Sources: Transient, Singleton, Scoped, PerResolve, PerBlock.

Pure.DI's advantage here is that the generator knows in advance where each object is stored and creates a field or local variable for it. Lifetime violations (captive dependencies), missing bindings, and dependency cycles are detected before the program starts. If an analyzed graph contains a structural error, the application will not compile.

Keyed Services and Tags

Autofac can register a service by name or by an arbitrary key:

builder.RegisterType<OnlineState>()
    .Keyed<IDeviceState>(DeviceState.Online);

builder.RegisterType<OfflineState>()
    .Keyed<IDeviceState>(DeviceState.Offline);

For run-time selection, Autofac provides IIndex<TKey, TValue>.

Source: named and keyed services in Autofac.

Pure.DI uses tags:

DI.Setup(nameof(Composition))
    .Bind<IDeviceState>(DeviceState.Online).To<OnlineState>()
    .Bind<IDeviceState>(DeviceState.Offline).To<OfflineState>()
    .Root<IDeviceState>("Online", DeviceState.Online);

Source: tags in Pure.DI.

This example uses the same IDeviceState, OnlineState, OfflineState, and DeviceState types as the Autofac snippet. A tag can be a string, enum value, type, null, default, or a smart tag.

In the example above, Pure.DI selects the root implementation by tag while generating the code. If a consumer needs to select one of the registered implementations by key at run time, it can receive an ordinary IReadOnlyDictionary<TKey, TValue>:

DI.Setup(nameof(Composition))
    .Bind(Tag.Unique).To((OnlineState state) =>
        new KeyValuePair<DeviceState, IDeviceState>(DeviceState.Online, state))
    .Bind(Tag.Unique).To((OfflineState state) =>
        new KeyValuePair<DeviceState, IDeviceState>(DeviceState.Offline, state))
    .Root<DeviceStateSelector>("DeviceStateSelector");

sealed class DeviceStateSelector(
    IReadOnlyDictionary<DeviceState, IDeviceState> states)
{
    public IDeviceState this[DeviceState state] => states[state];
}

Pure.DI generates the code that builds the dictionary in advance and validates the graph of every value, while the specific element is selected by key at run time. This contract does not couple the application class to a DI tool's API and serves a purpose similar to Autofac's IIndex<TKey, TValue>.

Source: dictionary injection in Pure.DI.

When the standard .NET API is required, a Pure.DI composition can also implement IKeyedServiceProvider.

Generic Bindings

Autofac registers an open generic type:

builder.RegisterGeneric(typeof(Repository<>))
    .As(typeof(IRepository<>));

Source: open generic components in Autofac.

Pure.DI uses a marker type:

DI.Setup(nameof(Composition))
    .Bind<IRepository<TT>>().To<Repository<TT>>();

Source: generic types in Pure.DI.

The binding registration looks similar, but Pure.DI creates concrete code separately for Repository<User> and Repository<Order>. This allows it to account for generic constraints, nested generic types, and tags—in other words, to determine the precise object type at compile time. A successful build confirms the structural correctness of the generated graph, but it does not rule out application exceptions in constructors, factories, interceptors, or resource-disposal code.

The distinction matters for Native AOT. The official Autofac documentation explicitly notes that an open generic type closed over a value type requires dynamic code at run time and can cause a DependencyResolutionException. In Pure.DI, the concrete closed types are known at compile time, so this issue does not arise.

Source: Native AOT and trimming in Autofac.

Generic Roots

Classic DI containers support registrations of open generic types, but resolve an already closed type such as IRepository<Order>. Pure.DI can make the composition root itself generic and transfer the constraints of its type parameters into the public API:

DI.Setup(nameof(Composition))
    .Hint(Hint.Resolve, "Off")
    .Bind().To<StreamSource<TTDisposable>>()
    .Bind().To<DataProcessor<TTDisposable, TTS>>()
    .Root<IDataProcessor<TTDisposable, TTS>>("GetProcessor");

var composition = new Composition();
var processor = composition.GetProcessor<Stream, double>();

interface IStreamSource<T>
    where T : IDisposable;

sealed class StreamSource<T> : IStreamSource<T>
    where T : IDisposable;

interface IDataProcessor<T, TOptions>
    where T : IDisposable
    where TOptions : struct;

sealed class DataProcessor<T, TOptions>(IStreamSource<T> source)
    : IDataProcessor<T, TOptions>
    where T : IDisposable
    where TOptions : struct;

For this root, Pure.DI generates an ordinary generic method:

public IDataProcessor<T, TOptions> GetProcessor<T, TOptions>()
    where T : IDisposable
    where TOptions : struct;

The calling code selects T and TOptions, and the C# compiler validates them. The universal Resolve method of a classic DI container cannot express this contract because it accepts an already constructed closed type. An equivalent would require a separate, manually written generic factory outside the container API.

A type parameter can determine not only the return type but also the type of a root argument. For example, combining RootArg<TT>("model") with Root<IPresenter<TT>>("GetPresenter") creates a method in which the model is supplied at run time and type correspondence is checked by the compiler:

public IPresenter<T> GetPresenter<T>(T model);

A root can also be asynchronous, accept ordinary run-time arguments, and preserve type constraints:

public Task<IQuery<TConnection, TResult>>
    GetDataQueryAsync<TConnection, TResult>(
        CancellationToken cancellationToken)
    where TConnection : IDisposable
    where TResult : struct;

These are not new variations of Resolve: Pure.DI generates typed methods whose signatures become part of the composition API.

Sources: Pure.DI generic roots with type constraints, generic root arguments, and asynchronous generic roots with constraints.

Factories and Relationship Types

Autofac calls Lazy<T>, Owned<T>, Func<T>, IEnumerable<T>, Meta<T>, and IIndex<TKey,TValue> relationship types. They can be combined—for example, as IEnumerable<Func<Owned<T>>>.

Source: implicit relationship types in Autofac.

Pure.DI supports the same core scenarios:

For example, both libraries automatically inject Func<IEnemy> into the same consumer:

sealed class GameLevel(Func<IEnemy> enemyFactory) : IGameLevel
{
    public IEnemy CreateEnemy() => enemyFactory();
}

Autofac registration:

builder.RegisterType<Enemy>().As<IEnemy>();
builder.RegisterType<GameLevel>().As<IGameLevel>();

Pure.DI registration and root:

DI.Setup(nameof(Composition))
    .Bind().To<Enemy>()
    .Bind().To<GameLevel>()
    .Root<IGameLevel>("GameLevel");

Source: on-demand injection in Pure.DI.

In Autofac, the delegate is a relationship type. In Pure.DI, it is generated as a strongly typed object-creation call. The application-level GameLevel does not depend on the choice of DI tool.

Pure.DI also supports Func<...> with arguments whose values are determined dynamically at run time:

DI.Setup(nameof(Composition))
    .Bind().As(Lifetime.Singleton).To<Clock>()
    .Bind().To<Person>()
    .Bind().To<Team>()
    .Root<Team>("Team");

The consumer receives a factory with two dynamic arguments:

sealed class Team(Func<int, string, IPerson> personFactory)
{
    public IPerson CreatePerson(int id, string name) =>
        personFactory(id, name);
}

The id and name values are supplied when the factory is called. Pure.DI obtains the IClock dependency, which Person also needs, from the composition. Statically known dependencies are therefore validated at compile time, while dynamic data is passed at run time.

Source: Func with arguments in Pure.DI.

Autofac also supports Func<X, Y, T> with run-time arguments:

builder.RegisterType<Clock>().As<IClock>().SingleInstance();
builder.RegisterType<Person>().As<IPerson>();

using var container = builder.Build();
var personFactory = container.Resolve<Func<int, string, IPerson>>();
var person = personFactory(10, "Nik");

For the standard Func<X, Y, T>, Autofac matches arguments to constructor parameters by type and obtains the remaining dependencies from the current lifetime scope. Such a Func does not support multiple arguments of the same type. For that case, Autofac provides custom delegate factories, whose parameters are matched by name.

Sources: Func<X, Y, T> in Autofac and delegate factories.

`Owned<T>`: Same Name, Different Implementation

Both libraries allow a consumer to explicitly own part of the object composition being created and dispose of it independently of the container or main composition. For example, the consumer can use a dependency such as Func<Owned<IMessageHandler>>:

sealed class MessagePump
{
    private readonly Func<Owned<IMessageHandler>> handlerFactory;

    public MessagePump(Func<Owned<IMessageHandler>> handlerFactory) =>
        this.handlerFactory = handlerFactory;

    public void Go()
    {
        while (true)
        {
            var message = NextMessage();

            using var handler = handlerFactory();
            handler.Value.Handle(message);
        }
    }
}

This is a form of the official example from the Autofac documentation on owned instances.

Autofac Setup

builder.RegisterType<MessageHandler>().As<IMessageHandler>();
// MessagePump receives Func<Owned<IMessageHandler>>.
builder.RegisterType<MessagePump>();

using var container = builder.Build();
var pump = container.Resolve<MessagePump>();

For each Owned<T>, Autofac creates a separate ILifetimeScope. Disposing Owned<T> ends the scope and disposes dependencies created within it that are not shared.

In Autofac 9.3.1, Owned<T> is a class. It replaces the lifetime-scope reference through Interlocked.Exchange, supports Dispose() and DisposeAsync(), and then delegates disposal to the lifetime scope.

Source: Owned.cs from Autofac 9.3.1.

Pure.DI Setup

DI.Setup(nameof(Composition))
    .Bind<IMessageHandler>().To<MessageHandler>()
    // MessagePump receives Func<Owned<IMessageHandler>>.
    .Bind().To<MessagePump>()
    .Root<MessagePump>("MessagePump");

var composition = new Composition();
var pump = composition.MessagePump;

Neither setup requires Owned<T> to be registered separately. Autofac supplies it as a relationship type, while Pure.DI recognizes Func<Owned<IMessageHandler>> in the MessagePump constructor and generates the factory together with disposal code for the object composition being created.

Sources: tracking disposable instances in Pure.DI delegates and OwnedTests.cs.

Internally, however, there is no specialized lifetime scope as in Autofac:

Owned<T> is a readonly struct containing the value and a reference to the disposal mechanism;
the generator knows all disposable objects in the specific dependency graph in advance;
a graph without resources uses a shared empty owner without a separate resource accumulator;
when the number of resources is known, the accumulator is created with an appropriate capacity, optimizing the list used to store resources;
with ThreadSafe = Off, the generator does not add unnecessary synchronization;
synchronous and asynchronous disposal are generated with the target .NET platform in mind.

The implementation handles synchronous and asynchronous disposal, reverse resource order, repeated and concurrent calls, nested owners, shared lifetimes, and rollback when graph creation fails. These scenarios are covered by comparative integration tests against Autofac.

Autofac provides a similar outcome in equivalent scenarios. Pure.DI's advantage here is that lifetime management is implemented in the generated code that creates the object composition. This approach does not require a special lifetime scope like Autofac and enables compile-time optimizations that are unavailable to a classic DI container.

Property and Method Injection, and Building Up Objects

Autofac supports required properties, PropertiesAutowired(), manual property assignment, and injection into an existing object through InjectProperties(). Method injection is usually configured with a lambda registration.

Source: property and method injection in Autofac.

Pure.DI supports injection through properties, fields, and methods directly in the generated code:

sealed class Navigator : INavigator
{
    public IMap? CurrentMap { get; private set; }

    [Dependency]
    public void LoadMap(IMap map) => CurrentMap = map;
}

Source: method injection in Pure.DI.

Build-Up is available for an existing object:

.Bind().To(ctx =>
{
    var person = new Person();
    ctx.BuildUp(person);
    return person;
})

TryBuildUp lets you safely check whether an object can be built up.

Sources: building up an existing object and builders with TryBuildUp.

Because the members are known to the generator at compile time, objects are completed directly by ordinary C# code and do not require .NET Reflection at run time.

Decorators and Interception

Autofac has a dedicated API:

builder.RegisterType<TextWidget>()
    .As<IWidget>();

builder.RegisterDecorator<BoxWidget, IWidget>();

Source: Autofac adapters and decorators.

In Pure.DI, the same chain is configured as follows:

DI.Setup(nameof(Composition))
    .Bind("base").To<TextWidget>()
    .Bind().To<BoxWidget>()
    .Root<IWidget>("Widget");

Both cases use TextWidget and BoxWidget. The only difference in the DI setup is that Pure.DI explicitly tags the decorated service:

sealed class BoxWidget([Tag("base")] IWidget inner) : IWidget
{
    public string Render() => $"[ {inner.Render()} ]";
}

The "base" tag is chosen arbitrarily for its meaning; it is not a “magic” value.

Source: decorators in Pure.DI.

This approach requires no special decorator logic at run time: decorators become part of the ordinary object composition, and the corresponding dependency graph is validated at compile time. For example, a single decorator class can decorate several objects of different types at once.

For interception, Autofac integrates with Castle DynamicProxy.

Source: type interception in Autofac.

Pure.DI provides the generated partial methods OnNewInstance and OnDependencyInjection. They can replace or wrap an instance at a selected point in the object composition without sacrificing performance. When a dynamic proxy object is genuinely required, Castle DynamicProxy can be integrated into the generated object-composition code.

Sources: interception in Pure.DI and advanced interception.

Autofac is more convenient when interception must be configured entirely at run time. Pure.DI is stronger when performance, transparency, and generation-time type filtering matter.

Modules and Large Compositions

Autofac modules encapsulate a set of registrations:

public sealed class RepositoryModule : Module
{
    protected override void Load(ContainerBuilder builder)
    {
        builder.RegisterType<SqlRepository>()
            .As<IRepository>();
    }
}

Source: Autofac modules.

Pure.DI splits the setup of large compositions into several parts:

DI.Setup("Infrastructure", CompositionKind.Internal)
    .Bind<IDatabase>().To<SqlDatabase>();

DI.Setup(nameof(Composition))
    .DependsOn("Infrastructure")
    .Bind<IUserService>().To<UserService>()
    .Root<IUserService>("UserService");

Sources: dependent compositions, global compositions, composition inheritance, setup context, and scope setup.

Compositions may be declared public, internal, or global. Composition inheritance, setup contexts, and separate scope setups are also available. These features make configuration reusable, and everything is processed at compile time.

Dynamic Autofac modules are better suited to assembling an application from a set of plugins that is not known in advance. Pure.DI compositions are better suited to modules defined at compile time: the graphs of declared roots are validated during the build.

Where Pure.DI Is Particularly Strong

A Graph Error Becomes a Build Error

Build() completes component registration and prepares the Autofac container, but does not perform full graph validation. Because registrations, parameters, modules, and factories can be dynamic, many errors are discovered only by a specific Resolve() call. A classic DI container therefore cannot always confirm in advance that every object composition created at run time will be valid.

Source: why registration analysis is not built into Autofac.

Pure.DI analyzes every declared root and reports:

missing bindings;
ambiguous implementation selection;
cyclic dependencies;
violations of generic type constraints;
an inaccessible constructor or other type member;
an incompatible tag;
nullable annotation issues;
invalid use of stack-only types;
and much more.

The developer gets structurally validated object-composition code before the application starts. Application code in constructors, factories, and interceptors retains its ordinary behavior and can still throw an exception at run time.

Composition Roots

In Autofac, the typical object-composition scenario is based on calling Resolve<T>(). In Pure.DI:

var report = composition.CreateReport(userId);
var worker = composition.Worker;

A composition root can be a property or a method with typed arguments and a typed result. Anonymous roots remain available through Resolve methods when needed, just as in Autofac.

Sources: composition roots and typed root arguments.

Native AOT Without Reflection in Generated Code

Autofac 9 supports trimming and Native AOT for basic scenarios, but documents the following limitations:

assembly scanning requires preserving types found through .NET Reflection;
an open generic type closed over a value type can produce a run-time error;
strongly typed metadata views require run-time expression compilation;
generated factories, delegate factories, and custom property selectors can produce RequiresDynamicCode or RequiresUnreferencedCode;
the absence of a warning for some relationship types does not guarantee full AOT compatibility.

Source: Native AOT and trimming in Autofac.

Pure.DI generates ordinary new calls. To the trimmer, this is normal statically linked C# code: the generator does not need to preserve constructors, methods, properties, and fields “just in case,” because everything required is already used directly. Application compatibility with Native AOT and trimming still depends on custom factories, interceptors, and third-party libraries.

Example: a Pure.DI console application with Native AOT.

Modern C# Becomes Part of the Object Composition

Pure.DI supports scenarios that cannot be represented through the universal object-based API of most classic DI containers:

Span<T> and ReadOnlySpan<T> as dependencies;
ref struct and factories with allows ref struct;
ref dependencies that preserve managed-reference semantics;
stack-only root arguments and generated scoped ReadOnlySpan<T> parameters;
ValueTask<T> roots;
nullable annotations as part of a DI contract;
union types as DI contracts.

In particular, T and T? have the same run-time type. A universal Resolve(Type) therefore cannot select between them as two separate contracts. Pure.DI analyzes nullable annotations in source code and preserves the distinction while validating and generating the graph.

An object-based API also cannot accept ReadOnlySpan<T> through object or params object[]: a stack-only value cannot be boxed. Pure.DI can instead generate a typed root:

public IRouteMatcher CreateMatcher(
    scoped ReadOnlySpan<char> path);

Managed references are also preserved when dependencies are injected:

[Ordinal]
public void Initialize(ref Data data);

Such an API can be written manually as an external factory, but it cannot be expressed through the universal object-based API of a classic DI container.

Sources: Span and ReadOnlySpan, ref dependencies, a factory with allows ref struct, method injection on a hot path, a factory with ReadOnlySpan<T>, a ValueTask<T> root, nullable reference types, union types, and a non-boxing union result.

Pure.DI can also generate interfaces from a class, preserving generic types, nullable annotations, events, and XML documentation.

Performance: The Overhead of a Classic DI Container

The BenchmarkDotNet suite in the repository compares creation of the same object composition by hand, through Pure.DI, and through Autofac—a classic DI container.

The following rows come from saved results produced with BenchmarkDotNet 0.15.8 and .NET SDK 10.0.102 on Windows 10 with an AMD Ryzen 9 5900X. The table shows the mean time per operation and the amount of allocated managed memory:

Scenario	Hand-written code	Pure.DI root	Autofac	Pure.DI memory	Autofac memory
Transient	2.820 ns	3.088 ns	13,207.209 ns	24 B	30,424 B
Singleton	2.745 ns	2.805 ns	8,143.869 ns	24 B	22,048 B
`Func<T>`	3.089 ns	2.774 ns	4,800.897 ns	24 B	13,128 B
Array	49.80 ns	51.32 ns	13,300.06 ns	408 B	26,496 B

Source: Pure.DI performance benchmarks. The result snapshot was saved in commit 91f5c2ee57dbccf2efa21959d7d8743ac1e9937e on February 14, 2026.

In this run, creating this particular transient graph through a generated Pure.DI root was approximately 4,276 times faster and allocated about 1/1,268 as much memory as resolving the same root through Autofac. These results apply to a specific object graph and benchmark environment. The ratio may change with a different graph structure, .NET version, hardware, or way of obtaining the root.

The difference follows from the architecture of the tools. Pure.DI generates specialized graph-creation code in advance, close to hand-written code. Autofac resolves dependencies through the universal mechanism of a classic DI container and applies lifetime rules while the program is running. Pure.DI's advantage is therefore not a particular result from one benchmark, but minimal overhead when creating a statically known graph.

Where Autofac Is Objectively Stronger

Assembly Scanning

Autofac can load an assembly, find suitable implementations, and register them at run time.

Source: assembly scanning in Autofac.

This is useful for plugins and extensions. The trade-offs are reliance on .NET Reflection, less explicit configuration, and additional trimming requirements.

Registration Sources and Resolve Pipelines

Autofac can dynamically provide a registration for an unknown type and add middleware to the resolve pipeline.

Sources: registration sources and resolve pipelines.

Frameworks and infrastructure libraries need this flexibility. In Pure.DI, similar behavior is usually implemented through a factory, an interception method, or specialized code.

Ready-Made Multitenancy Infrastructure

Autofac has a dedicated multitenant package and tenant-specific containers.

Source: multitenant applications in Autofac.

Pure.DI can create separate compositions for each tenant using tags, factories, composition arguments, or root arguments, but does not provide identical run-time capabilities.

If an application genuinely uses these capabilities, Autofac may be the better choice. Most applications, however, do not need a dynamic dependency graph to create object compositions.

Different Extensibility Models

Autofac describes features in container terms:

registration sources;
resolve pipelines;
service middleware;
lifetime scopes;
module scanning.

Pure.DI often solves the same application-level problems with ordinary C# code, although these are not always direct equivalents of Autofac features:

generic bindings or factories replace run-time registration sources;
generated partial methods replace resolve middleware;
an explicit typed decorator chain in the object composition replaces decorator discovery;
a lifetime scope for a unit of work is replaced by a generated Owned<T> optimized for a specific object composition;
a dependent composition replaces a run-time module;
ordinary properties or methods serve as composition roots instead of Resolve<T>(). Resolve<T>() methods are also supported and are highly efficient.

Conclusion

Autofac is indeed a powerful classic DI container. Its maturity, ecosystem, and dynamic run-time configuration capabilities deserve recognition.

That does not mean Pure.DI is less capable. For a .NET application with a dependency graph known in advance, the picture is different:

Pure.DI has counterparts for the core Autofac DI scenarios;
the dependency graph for every used root is validated during the build;
generated object-creation code does not require Reflection or dynamic code generation;
composition roots are strongly typed;
generated code can be read and debugged like ordinary C#;
generated code does not need to box values for the sake of a classic DI container's universal API;
Owned<T> gets a specialized, thoroughly tested resource-ownership model;
performance is close to hand-written code following the Pure DI paradigm.

A more precise formulation of the distinction is therefore:

Pure.DI implements the core scenarios of a classic DI container through code generation and validates the structure of statically known graphs during the build.

Autofac is justified when the composition structure must change at run time. When it is known in advance, Pure.DI builds and validates the graph, then generates the code. That work happens once, while the application is being built.

What's new in Pure.DI: union types, interface generation, and DI without unnecessary allocations

Nikolay Pianikov — Sun, 19 Jul 2026 09:38:55 +0000

Pure.DI is a dependency injection code generator that runs at compile time. It advances the idea of "pure DI": instead of a container and reflection, you get regular C# code that creates object compositions. This article covers the new features introduced in releases 2.3.5 through 2.5.1, from union types as DI contracts to dependency injection scenarios without unnecessary allocations.

The key benefits of Pure.DI are:

Zero overhead: the generator produces regular, statically typed C# code without runtime dependency lookup or reflection
Compile-time validation: DI graph configuration errors, cyclic dependencies, and missing bindings are detected during compilation
Broad compatibility: from .NET Framework 2.0 to modern .NET versions, Unity, Native AOT, and other platforms
Transparency: you can always inspect, debug, and understand the generated code

Six releases have shipped since the previous article, so this one is divided into two main parts.

Part 1. New features:

union types as DI contracts
generating interfaces from classes ([GenerateInterface])
implementation-level attribute bindings ([Bind], [Type], [Tag], [Lifetime])
[Export]: class members as dependency sources
custom binding attributes
scopes: SetupScope, per-scene Unity scopes, and CreateScope() for Microsoft DI
complete nullable reference type support
TryBuildUp for safe object build-up
support for new C# 13/14 features: OverloadResolutionPriority and partial constructors

Part 2. Performance - DI on hot paths:

Span<T>, ReadOnlySpan<T>, and ref struct dependencies
factories for stack-only values (allows ref struct)
zero-copy parsing and method injection on hot paths
diagnostics for stack-only values
non-boxing union results
a catalog of high-performance examples: ArrayPool, object pools, closure-free factories, ValueTask<T> roots, and ThreadSafe = Off
leaner generated code

Part 1. New features

Union types as DI contracts

Preview versions of C# introduced union types: a type whose value can be one of several predefined case types. Pure.DI can now use a union as a DI contract. A case implementation is implicitly converted to the union, and the generator builds the entire dependency graph of the selected case behind the union contract. Unlike an interface, case types do not need to share an abstraction. They can even be classes from unrelated third-party SDKs that you cannot modify.

DI.Setup(nameof(Composition))
    .Bind<IReceiptService>().To<ReceiptService>()
    // The composition decides which payment gateway
    // stands behind the union contract
    .Bind<PaymentGateway>().To<StripeGateway>()
    .Root<CheckoutService>("Checkout");

// The case types are independent classes with no common interface,
// and each one has its own dependencies
class StripeGateway(StripeApiClient api)
{
    public string Charge(int amountInCents) =>
        api.Post($"charge {amountInCents}");
}

class BankGateway(BankAccount account)
{
    public string Transfer(int amountInCents) =>
        $"bank transfer {amountInCents} from {account.Iban}";
}

// The case types are implicitly convertible to the union,
// and Pure.DI uses that conversion
union PaymentGateway(StripeGateway, BankGateway);

// The service depends on the union and handles each case explicitly
class CheckoutService(PaymentGateway gateway, IReceiptService receipts)
{
    public string Pay(int amountInCents)
    {
        var confirmation = gateway switch
        {
            StripeGateway stripe => stripe.Charge(amountInCents),
            BankGateway bank => bank.Transfer(amountInCents),
            _ => throw new InvalidOperationException("Unknown payment gateway.")
        };

        return receipts.Print(confirmation);
    }
}

Switching providers is a one-line change: .Bind<PaymentGateway>().To<BankGateway>(). Important details:

when there is no explicit union binding but exactly one registered binding can be converted to the union, Pure.DI resolves the union through that single case automatically
when several case bindings are applicable, Pure.DI reports DIE050 with the candidate list and binding locations
union types do not participate in auto-binding, so Pure.DI cannot accidentally create an "empty" union
the case binding retains ownership of its lifetime and disposal behavior; Singleton, Scoped, and PerResolve work as usual
collections of cases are assembled through Tag.Unique; consumers can request IEnumerable<PaymentGateway>, arrays, ReadOnlySpan<>, and other supported collection types

Union types: case implementations behind a union contract

Union type support requires a preview language version and .NET 11 Preview 5 or later, but it is already available to try.

Generating interfaces from classes

The classic "class plus matching interface" pair is some of the dullest boilerplate in DI-based applications. An interface can now be generated from its implementation: declare an empty partial interface and mark the class with [GenerateInterface]. Special thanks to Adam Hathcock for designing and implementing this feature.

DI.Setup(nameof(Composition))
    .Bind().To<EmailSender>()
    .Root<App>(nameof(App));

// Pure.DI generates the interface body for this empty declaration
public partial interface IEmailSender;

[GenerateInterface]
public class EmailSender : IEmailSender
{
    public string Provider => "smtp";

    public string Send(string address) => $"sent:{address}";
}

// The consumer depends on an abstraction nobody had to write manually
public class App(IEmailSender sender);

The feature goes beyond simple mirroring:

the interface name, namespace, and accessibility are configurable through named attribute arguments
one class can generate several interfaces, with members distributed between contracts by attributes
[IgnoreInterface] excludes members from the contract
generic members, nullable annotations, and events are preserved, along with XML documentation comments

Generating an interface from a class

Implementation-level attribute bindings

Version 2.5.0 redesigned the attribute binding model. This is a breaking change, with migration details below. [Bind] can now be declared directly on the implementation type and specify its contract, lifetime, and tag. Implementations can describe their own bindings, keeping composition setup concise:

DI.Setup(nameof(Composition))
    // The setup contains only the root; the attribute defines the binding
    .Root<IMessageWriter>("Writer", "console");

[Bind(typeof(IMessageWriter), Lifetime.Singleton, "console")]
class ConsoleMessageWriter : IMessageWriter
{
    public void Write(string message) => Console.WriteLine(message);
}

Attributes inside one [...] group are merged into a single binding, while separate groups create independent bindings. This is useful when one implementation plays several roles with different contracts, lifetimes, and tags:

// Binding group #1: payment pipeline participant
[Bind(typeof(IPaymentProcessor), Lifetime.Singleton, "audit")]
// Binding group #2: the same adapter as an audit sink with its own lifetime
[Bind(typeof(IPaymentAuditSink), Lifetime.Transient, "operations")]
class PaymentAuditAdapter(IEventStore eventStore) :
    IPaymentProcessor,
    IPaymentAuditSink;

In addition to [Bind], the focused [Type], [Tag], and new [Lifetime] attributes can be combined. Generic implementations support marker contracts such as typeof(IBox<TT>).

BindAttribute on an implementation

Bind attribute groups: several roles for one adapter

`[Export]`: class members as dependency sources

Previously, member-level dependency sources used [Bind]. That role now belongs to the new [Export] attribute, making the semantics unambiguous: [Bind] defines bindings, while [Export] defines dependency sources.

DI.Setup(nameof(Composition))
    .Bind().As(Lifetime.Singleton).To<DeviceFeatureProvider>()
    .Bind().To<PhotoService>()
    .Root<IPhotoService>("PhotoService");

class DeviceFeatureProvider
{
    // This property is a dependency source
    [Export] public IGps Gps { get; } = new Gps();

    [Export] public ICamera Camera { get; } = new Camera();
}

class PhotoService(IGps gps, Func<ICamera> cameraFactory) : IPhotoService;

[Export] accepts optional lifetime and tags values, so an exported member behaves like a binding source:

class GraphicsAdapter
{
    [Export(lifetime: Lifetime.Singleton, tags: ["HighPerformance"])]
    public IGpu HighPerfGpu { get; } = new DiscreteGpu();
}

class RayTracer([Tag("HighPerformance")] IGpu gpu) : IRenderer;

Migration from 2.4.x is straightforward: replace member-level [Bind] with [Export], and replace RootKinds.Exposed with RootKinds.Exported.

ExportAttribute: members as dependency sources

Export with a lifetime and tag

Custom binding attributes

If you do not want to annotate implementations with Pure.DI's built-in attributes, declare a custom attribute and register it in the setup. TypeAttribute<T>(), TagAttribute<T>(), and the new LifetimeAttribute<T>() tell the generator which constructor arguments contain the contract, tag, and lifetime. The version below uses Pure.DI.Lifetime, so the implementation assembly still needs a reference to the Pure.DI API:

DI.Setup(nameof(Composition))
    // Register the custom attribute as a binding metadata source
    .TypeAttribute<ServiceAttribute<TT>>()
    .LifetimeAttribute<ServiceAttribute<TT>>()
    .TagAttribute<ServiceAttribute<TT>>(1)
    .Root<IMessageWriter>("Writer", "console");

// The attribute can live with the implementations without depending
// on a particular built-in Pure.DI binding attribute
[AttributeUsage(AttributeTargets.Class, AllowMultiple = true)]
class ServiceAttribute<T> : Attribute
{
    public ServiceAttribute(
        Lifetime lifetime = Lifetime.Transient,
        object? tag = null)
    {
    }
}

[Service<IMessageWriter>(Lifetime.Singleton, "console")]
class ConsoleMessageWriter : IMessageWriter;

Custom attributes follow the same group merging rules as the built-in Bind, Type, Tag, and Lifetime attributes. Duplicate lifetime metadata within one attribute group is reported as an error.

Custom binding attribute

Scopes: `SetupScope`

A common requirement is a lifetime tied to a request or operation: a request context, unit of work, or telemetry scope. A new generated method, whose name is configured through ScopeMethodName, connects a new composition instance to its parent scope. Scoped instances are unique within the scope and are disposed with it, while a regular Singleton remains shared.

var composition = new Composition();

// Request #1: its own scope and RequestContext
using (var request = Composition.SetupScope(composition, new Composition()))
{
    var checkout = request.RequestRoot;
    // RequestContext is shared within this scope
    // and disposed when the scope ends
}

partial class Composition
{
    static void Setup() => DI.Setup()
        .Hint(Hint.ScopeMethodName, "SetupScope")
        // Per-request lifetime
        .Bind().As(Scoped).To<RequestContext>()
        .Bind().As(Singleton).To<IdGenerator>()
        .Bind().To<CheckoutService>()
        .Root<ICheckoutService>("RequestRoot");
}

The method name can match the domain: CreateScope, BeginRequest, or OpenSession. Scopes can also be created through factory methods, and Pure.DI validates that the parent and child scopes are different, preventing accidental self-nesting.

Scope setup method: a request scope without a wrapper class

Platform scopes: Unity scenes and Microsoft DI

The same scope model maps naturally to platform scenarios. In Unity, each loaded scene gets its own scope: Scoped services are shared within the scene and isolated between scenes, while Singleton services are shared by the entire application. Unity creates MonoBehaviour objects itself, and Pure.DI builds them up through builders:

public partial class Scope : MonoBehaviour
{
    [SerializeField] ClockConfig clockConfig;

    void Setup() => DI.Setup()
        .Hint(Hint.ScopeMethodName, "SetupScope")
        .Bind().To(() => clockConfig)
        .Bind<IClockService>().As(Singleton).To<ClockService>()
        .Bind<IClockSession>().As(Scoped).To<ClockSession>()
        // Unity creates MonoBehaviour; Pure.DI builds it up
        .Builders<MonoBehaviour>();
}

Unity scene scopes: one scope per scene

For integration with Microsoft.Extensions.DependencyInjection, a composition can implement IServiceScopeFactory and IServiceScope. Every composition.CreateScope() call creates a new scope, and tags can be mapped to keyed services. This model is compatible with Microsoft DI scoped semantics for explicitly declared composition roots. Only roots registered through Root(...) or RootBind() can be resolved through IServiceProvider.

Service provider with Microsoft DI-compatible scopes

Nullable reference types end to end

Version 2.4.0 introduced complete support for nullable reference types. Annotations are preserved while reading contracts, building the graph, and generating code. This is a breaking change: code that relied on automatic null checks for nullable arguments may need adjustment.

DI.Setup(nameof(Composition))
    .Bind<IDatabase>().To<Database>()
    .Bind<IReportService>().To<ReportService>()
    // Nullable arguments no longer receive null checks:
    // null is passed through as intended
    .Arg<string?>("defaultTitle", "title")
    .RootArg<string?>("connectionString", "connection")
    .Root<IReportService>("CreateReportService");

var composition = new Composition(defaultTitle: null);
var reportService = composition.CreateReportService(connectionString: null);

class ReportService(
    [Tag("title")] string? defaultTitle,
    [Tag("connection")] string? connectionString,
    IDatabase? optionalDatabase) : IReportService;

The practical effects are:

a non-null binding can satisfy a nullable dependency, which is useful for optional constructor parameters, nullable factory results, and collection elements
T? means that the consumer can handle null, but it does not suppress a graph error when no binding exists
for generic contracts with nullable arguments, prefer where T : class? over where T : class to avoid compiler warnings
new warnings highlight ambiguous nullable roots in Resolve methods

Nullable reference types: examples and recommendations

`TryBuildUp`: safe object build-up

Builders complete objects created by external systems such as UI frameworks, serializers, or Unity. Strict BuildUp throws ArgumentException when the runtime subtype is unknown to the composition. Pure.DI now generates a safe TryBuildUp method alongside BuildUp, avoiding that exception:

DI.Setup(nameof(Composition))
    .Bind().To(Guid.NewGuid)
    .Bind().To<PlutoniumBattery>()
    // Generate a builder for every IRobot subtype matching *Bot
    .Builders<IRobot>("BuildUp", filter: "*Bot");

var composition = new Composition();

// Known type: build-up succeeds
var cleaner = composition.BuildUp(new CleanerBot());

// Unknown subtype: graceful fallback instead of an exception
var externalRobot = new ExternalRobot();
if (!composition.TryBuildUp(externalRobot))
{
    // The object remains untouched; handle the situation here
}

This is especially useful when objects arrive from outside and their concrete runtime type is not known in advance: deserialization, plugins, and Unity scene objects.

Builders and TryBuildUp

New C# 13/14 features: partial constructors and `OverloadResolutionPriority`

C# 14 allows a constructor declaration, or contract, to be separated from its body. For example, the contract with DI attributes can live in one part of a partial class while the logic lives in another, possibly generated, part. Pure.DI sees the combined constructor and handles it like a regular one:

partial class AuditSink : AuditSinkBase
{
    // The defining declaration participates in constructor selection,
    // and parameter attributes are combined with the implementation
    public partial AuditSink(
        [Tag("durable")] IAuditTransport transport,
        AuditSinkOptions options);
}

partial class AuditSink
{
    // Place the base(...) or this(...) initializer on the implementation
    public partial AuditSink(
        IAuditTransport transport,
        AuditSinkOptions options)
        : base(transport)
    {
        BatchSize = options.BatchSize;
    }
}

Partial constructor injection

Pure.DI also supports OverloadResolutionPriorityAttribute, introduced in C# 13. The attribute raises or lowers the priority of a constructor overload:

[method: OverloadResolutionPriority(1)]
class BillingApiClient(ResilientHttpOptions options)
{
    // Keep the legacy constructor for existing callers while newly
    // compiled code, including Pure.DI output, prefers the primary one
    public BillingApiClient(LegacyHttpOptions options)
        : this(new ResilientHttpOptions()) { }
}

The rules follow C#: higher values are preferred, unannotated constructors have priority 0, and negative values lower a constructor's priority. [Ordinal] remains Pure.DI's explicit, stronger selection mechanism. DIW014 concerns a different case, method injection: it warns that a regular generated method call can resolve to another overload with a higher OverloadResolutionPriority.

OverloadResolutionPriority in constructor selection

Part 2. Performance: DI on hot paths

In Pure.DI, "zero overhead" means regular, statically typed code without a runtime container. Release 2.5.1 goes further: dependency injection now works in stack-oriented code with Span<T> and ref struct without requiring wrappers or runtime lookup. Potentially unsafe ways of storing stack-only values are diagnosed while the DI graph is built.

`Span<T>` and `ReadOnlySpan<T>` as dependencies

Span injection works like T[] injection for immediate use in a constructor or method. For value types, Pure.DI generates stackalloc, so the dependency collection itself is assembled without a heap allocation.

DI.Setup(nameof(Composition))
    .Bind<Point>('a').To(() => new Point(1, 1))
    .Bind<Point>('b').To(() => new Point(2, 2))
    .Bind<Point>('c').To(() => new Point(3, 3))
    .Bind<IPath>().To<Path>()
    .Root<IPath>("Path");

readonly struct Point(int x, int y);

class Path(ReadOnlySpan<Point> points) : IPath
{
    // The span is allocated on the stack and is inexpensive.
    // A ref struct cannot be stored in a field,
    // but it can be processed immediately in the constructor
    public int PointCount { get; } = points.Length;
}

Constructor injection of a ref struct into a heap type remains available for compatibility but reports DIW012. Method injection, described below, is the preferred approach for new stack-only code.

Span and ReadOnlySpan

Factories for stack-only values

Starting with C# 13, the standard Func<TArg, TResult> can accept a ref struct when its generic parameters are declared with allows ref struct. Compatible reference assemblies from a modern BCL are also required. Pure.DI provides a safe default binding for Func<ReadOnlySpan<char>, T>: the span remains local to the synchronous factory invocation and is passed immediately into the object graph being created.

DI.Setup(nameof(Composition))
    .Root<Func<ReadOnlySpan<char>, Parser>>("ParserFactory");

var composition = new Composition();
var parser = composition.ParserFactory("Hello".AsSpan());

class Parser
{
    [Ordinal]
    public void Initialize(ReadOnlySpan<char> text) { /* ... */ }
}

Default Func with ReadOnlySpan

Custom generic delegates with where T : allows ref struct are also supported. A stack-only value is passed through ctx.Override(...) and consumed immediately. In a thread-safe context, the override and injection stay inside lock (ctx.Lock):

delegate bool ParserFactory<in T>(T text)
    where T : allows ref struct;

DI.Setup(nameof(Composition))
    .Bind<ParserFactory<ReadOnlySpan<char>>>().To(ctx => new ParserFactory<ReadOnlySpan<char>>(text =>
    {
        lock (ctx.Lock)
        {
            ctx.Override<ReadOnlySpan<char>>(text);
            ctx.Inject<Parser<ReadOnlySpan<char>>>(out var parser);
            return parser.Initialized;
        }
    }))
    .Root<ParserFactory<ReadOnlySpan<char>>>("ParserFactory");

allows ref struct also works in generic roots and root arguments. Bind<T>(), RootBind<T>(), Root<T>(), and DefaultLifetime<T>() accept ref-like contracts. Transient<T>(), PerResolve<T>(), and PerBlock<T>() allow ref-like results that remain local while the root is being built. Singleton<T>() and Scoped<T>() can accept ref-like dependencies in a parameterized factory, but its stored result must be heap-safe; otherwise Pure.DI reports DIE046.

Allows ref struct factory

Zero-copy parsing and method injection on a hot path

When a service has long-lived stable dependencies but receives different data on every call, the per-call value can be passed as a root argument and consumed immediately by an injection method. As a C# 14 bonus, a byte[] root argument can satisfy a ReadOnlySpan<byte> injection contract. Pure.DI applies the compiler-provided span conversion, allowing the parser to read the caller-owned array without copying it.

DI.Setup(nameof(Composition))
    .Bind<IMessageRegistry>().To<MessageRegistry>()
    .Bind<IPacketHandler>().To<PacketHandler>()
    .RootArg<byte[]>("frame")
    .Root<IPacketHandler>("Handle");

var composition = new Composition();
// The caller retains ownership of the array and can return it
// to a pool after the call completes
var packet = composition.Handle(frame);

sealed class PacketHandler(IMessageRegistry registry) : IPacketHandler
{
    [Ordinal(0)]
    public void Decode(ReadOnlySpan<byte> frame)
    {
        var messageId = BinaryPrimitives.ReadUInt16BigEndian(frame);
        // Zero-copy packet parsing...
    }
}

Zero-copy network packet parsing

When the argument itself is stack-only, for example .RootArg<ReadOnlySpan<char>>("path"), the generated method root gets a scoped parameter. The compiler guarantees that the value does not outlive the current stack frame. Typical use cases include parsers, routers, protocol decoders, and validation pipelines.

Method injection for a hot path

Diagnostics for stack-only values

Stack-oriented code makes subtle mistakes easy. Pure.DI moves these failures to compile time with a dedicated set of diagnostics:

DIE046 - a stack-only dependency cannot use a stored lifetime such as Singleton or Scoped
DIE047 - a stack-only dependency cannot be injected into a field or property
DIE048 - a stack-only implementation cannot be injected through an interface conversion
DIE049 - a stack-only dependency cannot be captured by a generated delegate or deferred factory
DIW012 - warns about injecting a stack-only dependency into the constructor of a heap type
DIW013 - warns about an unsynchronized stack-only override in a thread-safe context

Instead of an obscure C# compiler error such as CS9244, Pure.DI can now report a dedicated diagnostic with an explanation and documentation link.

Pure.DI diagnostics reference

Non-boxing union results

Returning to union types from a performance perspective, the compact union representation stores its value as object, which boxes value-type cases. Hot paths can instead use custom union results that store each value-type case in a dedicated field, avoiding boxing, reflection, and wrapper allocations.

DI.Setup(nameof(Composition))
    // CacheHit is a value-type case of CacheLookupResult
    .Bind<CacheLookupResult>().To<CacheHit>()
    .Root<CacheLookupResult>("CachedProduct");

var result = new Composition().CachedProduct;
// Allocation-free access to the result
if (result.TryGetValue(out CacheHit hit)) { /* ... */ }

readonly record struct CacheHit(int ProductId, decimal Price);

readonly record struct CacheMiss(int ProductId);

// The custom union stores value-type cases directly
[System.Runtime.CompilerServices.Union]
readonly struct CacheLookupResult : System.Runtime.CompilerServices.IUnion
{
    private readonly byte _kind;
    private readonly CacheHit _hit;
    private readonly CacheMiss _miss;

    public CacheLookupResult(CacheHit hit) =>
        (_kind, _hit, _miss) = (1, hit, default);

    public CacheLookupResult(CacheMiss miss) =>
        (_kind, _hit, _miss) = (2, default, miss);

    public bool TryGetValue(out CacheHit value)
    {
        value = _hit;
        return _kind == 1;
    }

    // Value is the required general fallback and boxes a value-type case;
    // use it only for diagnostics
    public object? Value => _kind switch
    {
        1 => _hit,
        2 => _miss,
        _ => null
    };
}

Non-boxing union result

High-performance example catalog

The new capabilities are accompanied by a series of "DI on a hot path" examples:

ArrayPool buffers - ArrayPool<T> is supported out of the box; request ArrayPool<byte> like any other dependency and return the buffer to the pool when its owner is disposed through Owned<T>
Object pool - a Singleton pool of warm objects plus a short-lived lease for each root call, making reuse explicit and keeping leases within their scope
Factories without closure capture - dependencies are lambda parameters, such as .To((CurrencyFormatter currency, TaxPolicy tax) => ...), instead of captured values, keeping factory code deterministic and allocation-friendly
Struct dependencies - a small value-type dependency is created directly and does not require a separate heap allocation
ValueTask roots - a root such as Root<ValueTask<IFeatureSnapshot>> avoids allocating a Task<T> in the synchronous case
ThreadSafe = Off - when a composition is created and used on one thread, such as in a CLI tool or game-loop initialization phase, .Hint(Hint.ThreadSafe, "Off") removes generated synchronization

Code generation optimizations

the _lock field is now generated only when at least one lock (...) statement actually references it; previously every composition reserved space for it
all generated code is marked with [GeneratedCode], allowing analyzers, coverage tools, and code-style tools to recognize and optionally exclude it according to their settings; the generated class also contains the actual Pure.DI package version
graph construction and generation now use caching, prefer cheaper syntax analysis where it is sufficient, and avoid some repeated graph construction attempts, reducing generator overhead during compilation

Useful extras

A few smaller additions that do not need their own sections:

New factory context properties. ctx.RootName, ctx.RootType, and ctx.IsLockRequired join ctx.Tag, ctx.ConsumerType, and ctx.Lock:

// The logger knows which root is constructing it
.Bind().To(ctx => new Logger(ctx.RootName))

// Lock only when it is actually required
.Bind().To(ctx =>
{
    if (ctx.IsLockRequired)
    {
        lock (ctx.Lock) { /* ... */ }
    }
    // ...
})

Dictionary injection. IReadOnlyDictionary<TKey, TValue> is assembled automatically from KeyValuePair<TKey, TValue> bindings marked with Tag.Unique, making runtime implementation selection by key straightforward:

.Bind(Tag.Unique).To((EmailChannel c) => new KeyValuePair<Channel, INotificationChannel>(Channel.Email, c))
.Bind(Tag.Unique).To((SmsChannel c) => new KeyValuePair<Channel, INotificationChannel>(Channel.Sms, c))

class NotificationService(IReadOnlyDictionary<Channel, INotificationChannel> channels);

Dictionary: select a dependency by key

More BCL types out of the box. TimeProvider, TaskCompletionSource<T>, CultureInfo, IFormatProvider, StringComparer, IReadOnlySet<T>, RandomNumberGenerator, and other types can be injected without additional setup. A default binding can be overridden when necessary.

Factories with up to 16 parameters, and an update to Roslyn 5.6.

Uno Platform example. A cross-platform application using the single-project Uno SDK: a composition exposed as a XAML resource, virtual roots for view models, and DesignTimeComposition with override roots for the designer, all without a runtime container. Read the detailed example.

Conclusion

To try the new features, start with any example. Each example is independent and easy to run with dotnet run. If something is missing, feel free to open an issue in the Pure.DI GitHub repository.

Thank you for your interest and for reading to the end!

Pure.DI: DI without container, without .NET type reflection, and with compile-time validation

Nikolay Pianikov — Tue, 17 Mar 2026 10:48:32 +0000

Pure.DI is a C# code generator for dependency injection that builds the dependency graph at compile time and generates ordinary C# code for object creation. As a result, you get "pure DI": no service locator, no reflection, and problems detected at compile time.

This article covers the basic capabilities of Pure.DI. It is intended for developers who write in C#, have already encountered DI containers, and want to:

improve DI predictability and performance;
see the real object graph instead of a "magical" runtime container;
detect DI configuration errors at compile time;
use DI in environments where .NET Reflection is undesirable (AOT, Unity, older frameworks, library projects).

Details: Pure.DI README

DI: what we are actually trying to solve

Imagine a typical application scenario: a service processes an order, logs events, and interacts with an external payment gateway.

If dependencies are created "inside" services, the code quickly turns into a tangle:

// Bad: the service itself determines what and how to create
sealed class CheckoutService
{
    private readonly HttpClient _http = new();
    private readonly PaymentGatewayClient _gateway;
    private readonly ILogger _logger = new ConsoleLogger();

    public CheckoutService()
    {
        _gateway = new PaymentGatewayClient(_http, apiKey: "hardcoded");
    }

    public Task CheckoutAsync(Order order) => _gateway.PayAsync(order);
}

The problems here are standard:

Testing: difficult to replace PaymentGatewayClient and HttpClient.
Configuration: API keys and settings end up inside business code.
Lifetime: who and when should release resources?
Tight coupling: domain logic starts to depend on infrastructure.

DI is just a tool: an object should not create its dependencies; they are passed to it from the outside. Most often — through the constructor.

sealed class CheckoutService(IPaymentGateway gateway, ILogger logger)
{
    public Task CheckoutAsync(Order order) => gateway.PayAsync(order);
}

The question arises: who will create IPaymentGateway, ILogger, and CheckoutService itself?

The answer is composition of the application.

Pure DI: "no container", but dependency injection exists

In the classic approach, you configure a DI container, and then at runtime the container builds the dependency graph and provides objects on request.

Pure DI — an approach where there is no container as a runtime entity. There are only:

object composition (how to assemble the graph into a concrete object),
composition roots — entry points from which the needed composition is built.

In an ideal world, you want:

object creation to be done by ordinary code (without reflection and dynamic calls),
object composition to be transparent and debuggable,
errors like "missing dependency" or "cycle in graph" to be detected before production.

This is exactly what Pure.DI does.

What is Pure.DI — in simple terms

Pure.DI is a compile-time DI code generator: you define the dependency graph (bindings, tags, lifetimes, roots), and the generator:

analyzes this dependency graph at compile time;
verifies that the graph is correct (no "holes", cycles, inaccessible constructors, etc.);
generates a partial composition class with ordinary properties/methods that create object compositions, with roots as "initial" objects of the composition.

The obvious key advantages of this approach:

Zero Overhead: at runtime there is no container, no assembly scanning, no type reflection; exactly what you would write by hand is created — a chain of new.
Compile-Time Validation: DI configuration errors become compilation errors/warnings.
Works everywhere: no runtime dependencies — can be used even in .NET Framework 2.0+, or in AOT/Unity scenarios.
Transparency: you can view and debug the generated code just like your regular code.
Built-in BCL Support: many types from .NET BCL (Func<>, Lazy<>, IEnumerable<>, Task, ValueTask, Span, Tuple, etc.) are supported "out of the box".

Why this is better than a "regular" DI container in real work

Below are only practical advantages.

Predictable performance

If DI is reduced to generated code new A(new B(new C())), then:

no costs for reflection/dynamics;
no hidden allocations for graph construction;
no other "magic", which simplifies profiling and optimization.

Errors — at compile time, not at runtime

In a classic container, you may not notice a registration error for a long time, until the execution path (possibly very rare) leads to a problematic object graph. Pure.DI builds the graph in advance — and immediately reports problems. Problematic code simply won't compile, no matter how hard you try.

Clear composition roots instead of endless `Resolve<T>()`

In Pure.DI, composition roots are explicit properties or methods. This disciplines the architecture: you know exactly what objects your "container" provides externally. No Service Locator.

Convenient for libraries and limited environments

If you are writing a library, module, plugin, Unity code, or an AOT application — the absence of runtime dependencies and reflection often becomes a decisive factor.

Quick start

Before starting, it's useful to know two technical requirements (and it's important to understand that they relate to the generator, not your application):

.NET SDK 6.0.4+ is required for compilation (however, projects can target older platforms, down to .NET Framework 2.0+);
C# 8+ is required only for projects where the Pure.DI source generator is enabled (other projects in the solution can be on any version of C#).

What packages exist (most often you only need the first one):

Pure.DI — DI code generator;
Pure.DI.Abstractions — common abstractions/attributes;
Pure.DI.MS — additions for integration with Microsoft DI;
Pure.DI.Templates — templates for creating projects from the command line.

Minimal example: there is a service that sends emails, and we want to create it through DI.

1) Add the package:

Pure.DI on NuGet

2) Describe bindings and composition root:

using Pure.DI;

DI.Setup(nameof(Composition))
    .Bind<IClock>().To<SystemClock>()
    .Bind<IEmailSender>().To<SmtpEmailSender>()
    .Bind<INotificationService>().To<NotificationService>()
    // Composition root: public entry point into the graph
    .Root<INotificationService>("Notifications");

var composition = new Composition();
composition.Notifications.SendWelcome("dev@company.com");

interface IClock
{
    DateTimeOffset Now { get; }
}

sealed class SystemClock : IClock
{
    public DateTimeOffset Now => DateTimeOffset.UtcNow;
}

interface IEmailSender
{
    void Send(string to, string subject, string body);
}

sealed class SmtpEmailSender(IClock clock) : IEmailSender
{
    public void Send(string to, string subject, string body)
    {
        // Real sending would be here
        Console.WriteLine($"[{clock.Now:u}] -> {to}: {subject}");
    }
}

interface INotificationService
{
    void SendWelcome(string email);
}

sealed class NotificationService(IEmailSender sender) : INotificationService
{
    public void SendWelcome(string email) =>
        sender.Send(email, "Welcome!", "We are glad to see you in the system.");
}

At this step, the generator will create a partial class Composition and a property Notifications that returns the assembled graph. It's very simple.

See also real examples in the repository:

Composition class

From an architectural perspective, Composition is the place where:

bindings are defined: "use SmtpEmailSender instead of IEmailSender";
roots are defined: "externally we expose only INotificationService Notifications";
dependency lifetimes are configured;
(optionally) hints are set for the generator.

An important point: Pure.DI does not "hide" somewhere at runtime. A regular class appears in the project that can be opened, debugged, and studied in detail.

See also:

Bindings: how to link interfaces with implementations

Basic binding form:

.Bind<IContract>().As(Lifetime).To<Implementation>()

This is exactly what you're used to seeing in DI containers, but the result will be generated code.

Real scenario: two delivery methods — courier and parcel locker. Business code depends on IDeliveryService, and the specific implementation is chosen at the composition level - infrastructure specialized for creating objects of specific types.

using Pure.DI;

DI.Setup(nameof(Composition))
    .Bind<IDeliveryService>().To<CourierDelivery>()
    .Bind<IOrderService>().To<OrderService>()
    .Root<IOrderService>("Orders");

var composition = new Composition();
composition.Orders.PlaceOrder();

interface IDeliveryService
{
    void Ship();
}

sealed class CourierDelivery : IDeliveryService
{
    public void Ship() => Console.WriteLine("A courier is on his way");
}

interface IOrderService
{
    void PlaceOrder();
}

sealed class OrderService(IDeliveryService delivery) : IOrderService
{
    public void PlaceOrder()
    {
        // business logic...
        delivery.Ship();
    }
}

See also:

Example of binding abstractions to implementations

Automatic bindings: convenient, but be vigilant

Pure.DI can create non-abstract types without explicit bindings. This is convenient for small applications, utilities, and demos: you declare a root, and dependencies are "pulled" automatically.

using Pure.DI;

DI.Setup(nameof(Composition))
    .Root<ReportService>("Reports");

var composition = new Composition();
var service = composition.Reports;

sealed class FileSystem;

sealed class ReportService(FileSystem fs);

However, in a real application, automatic binding quickly hits architectural limitations:

harder to follow the dependency inversion principle (you start depending on concrete classes);
harder to manage different implementations of the same abstractions and decorators.

Therefore, the typical recommendation is to depend on abstractions and explicitly bind them to implementations.

See also:

Example of automatic binding

Factories: when you need more than just calling a constructor

Sometimes an object cannot be created only through a constructor:

manual initialization is needed (connect to DB, warm up cache, assemble config);
object is created through a third-party API;
additional verification/configuration is needed.

In Pure.DI, there is a binding to a factory for this:

using Pure.DI;

DI.Setup(nameof(Composition))
    .Bind<IDbConnection>().To<DbConnection>(ctx =>
    {
        // Inject() creates DbConnection with all dependencies (if any)
        ctx.Inject(out DbConnection conn);
        conn.Open();
        return conn;
    })
    .Bind<IRepository>().To<Repository>()
    .Root<IRepository>("Repo");

var composition = new Composition();
var repo = composition.Repo;

interface IDbConnection;

sealed class DbConnection : IDbConnection
{
    public void Open() { /* ... */ }
}

interface IRepository;

sealed class Repository(IDbConnection connection) : IRepository;

And if the factory is simple, you can describe it briefly — lambda parameters will be injected automatically:

using Pure.DI;

DI.Setup(nameof(Composition))
    .Bind().To(() => DateTimeOffset.UtcNow)
    .Bind<ILogFileName>().To((DateTimeOffset now) =>
        new LogFileName($"app-{now:yyyy-MM-dd}.log"))
    .Root<ILogFileName>("LogName");

var composition = new Composition();
Console.WriteLine(composition.LogName.Value);

interface ILogFileName
{
    string Value { get; }
}

sealed record LogFileName(string Value) : ILogFileName;

See also:

Simplified bindings: when the contract can be determined automatically

In large projects, the routine is not DI as a concept, but the number of lines of its configuration. Pure.DI allows simplifying the records.

Bind().To<Implementation>() binds the type itself and its non-special abstractions that it directly implements.

DI.Setup(nameof(Composition))
    .Bind().To<SmtpEmailSender>()
    .Root<IEmailSender>("Sender");

var composition = new Composition();
composition.EmailSender.Send("...");

interface IEmailSender { ... }

class SmtpEmailSender : IEmailSender { ... }

This is useful when a class implements one or more "regular" contracts, and you don't want to list them manually.

There are variants of "binding by lifetime" through methods Singleton<>(), PerResolve<>(), etc.

DI.Setup(nameof(Composition))
    .Singleton<SystemClock>()
    .Transient<EmailSender>()
    .Root<IEmailSender>("Sender");

var composition = new Composition();
composition.EmailSender.Send("...");

interface ISystemClock;

sealed class SystemClock: ISystemClock;

interface IEmailSender { ... }

class EmailSender(ISystemClock clock): IEmailSender { ... }

See also:

Tags: multiple implementations of one contract

In a real application, there are often several implementations of one interface:

different logging methods (file, console, telemetry);
different API clients (public/internal);
different payment providers (credit card/bank transfer/gift certificates).

Tags allow you to select an implementation explicitly without creating additional interfaces:

using Pure.DI;

DI.Setup(nameof(Composition))
    .Bind<IPaymentClient>("Sandbox").To<SandboxPaymentClient>()
    .Bind<IPaymentClient>("Prod").To<ProdPaymentClient>()
    .Bind<CheckoutService>().To<CheckoutService>()
    .Root<CheckoutService>("Checkout");

var composition = new Composition();
var root = composition.Checkout;

interface IPaymentClient;

sealed class SandboxPaymentClient : IPaymentClient;

sealed class ProdPaymentClient : IPaymentClient;

sealed class CheckoutService(
    [Tag("Prod")] IPaymentClient client)
{
    // ...
}

See also:

Lifetimes

Pure.DI supports familiar lifetimes. Important: this is not a "DI feature", but a tool for resource management and state isolation.

Below is a simplified cheat sheet (in terms of behavior):

Lifetime	When created	When the same instance is reused
`Transient`	from scratch each time	never
`Singleton`	once per `Composition` instance	everywhere within a single composition
`PerResolve`	on each access to a root	within one root
`PerBlock`	inside a construction block	allows reducing the number of instances (details depend on the graph)
`Scoped`	on a scope-composition	within one scope

Practical guideline:

Transient — safe default for most stateless services.
Singleton — for caches/pools/metadata, but requires thread safety and carefulness.
Scoped — for "request resources": DbContext/UnitOfWork/RequestTelemetry.

See also:

Composition arguments: how to pass external state without global static variables

DI combines poorly with passing additional external state (some data) to the created object. But in Pure.DI, Composition arguments turn external state into dependencies available in the graph like any others:

using Pure.DI;

DI.Setup(nameof(Composition))
    .Bind<IApiClient>().To<ApiClient>()
    .Root<IApiClient>("Api")
    .Arg<string>("baseUrl")
    .Arg<string>("token", "api token");

var composition = new Composition(
    baseUrl: "https://api.company.com",
    token: "secret");

var api = composition.Api;

interface IApiClient;

sealed class ApiClient(
    string baseUrl,
    [Tag("api token")] string token) : IApiClient;

See also:

Example of composition arguments

Root arguments: when parameters are needed only at one entry point

Sometimes values should be passed not to Composition, but to a specific root: for example, a command handler receives userId, and the rest of the composition does not depend on it.

For this, there are Root arguments. Such a root becomes a method:

using Pure.DI;

DI.Setup(nameof(Composition))
    // RootArg is incompatible with Resolve methods (better to disable)
    .Hint(Hint.Resolve, "Off")
    .RootArg<Guid>("userId")
    .Bind<IUserService>().To<UserService>()
    .Root<IUserService>("CreateUserService");

var composition = new Composition();
var service = composition.CreateUserService(userId: Guid.NewGuid());

interface IUserService;

sealed class UserService(Guid userId) : IUserService;

See also:

Example of root arguments

Generation and usage: roots as properties (and why this is convenient)

A key feature of Pure.DI — composition roots become regular class members, properties or methods.

This changes the usage style:

the root is easy to substitute in UI-binding (WPF/MAUI/Avalonia), because it's a property/method;
IDE and compiler help with navigation;
easy to document;
a dependency only participates in composition if you explicitly declared a root for it.

If desired, you can resolve dependencies through Resolve, but it's better to perceive this as "familiar, but not always rational approach".

See also:

Resolve methods and their limitations

Resolve methods: convenient, but it's Service Locator

Pure.DI can generate Resolve<T>() and Resolve(Type) methods — this is sometimes useful, for example, for integration with code that prefers to work with classic DI containers. But essentially this is Service Locator, with all the classic drawbacks:

API allows "getting anything" — this is loss of control;
there is a risk of runtime exceptions, for example, when there is no corresponding binding to a specific (non-abstract) type;
code becomes harder to analyze and test.

If you want a strict and clean architecture, Resolve is usually disabled:

using Pure.DI;

DI.Setup(nameof(Composition))
    .Hint(Hint.Resolve, "Off")
    // ...
    .Root<App>("App");

See also:

Resolve hint (enable/disable)

Dependency injection methods

In most projects, constructor injection is sufficient — it's simpler, safer, and well-supported by analyzers/IDE.

But sometimes other options are convenient (for example, when "building up" an object created externally).

Pure.DI supports:

injection through constructor;
injection through properties;
injection through fields;
injection through methods.

Properties, fields, and methods just need to be marked with the [Dependency] attribute or others like [Ordinal], [Tag], [Type], [Inject]. But you can always easily extend them with your own attributes, thereby making your code completely independent of DI.

See also:

Builders (BuildUp): when it's not possible to control object creation

Sometimes an object appears "from outside":

deserialization (JSON → object);
plugins/scripts;
game entities created by the engine;
UI elements created by the framework.

In such cases, the BuildUp pattern is useful: you already have an instance, and you want to "add" dependencies to it through fields/properties/methods marked with injection attributes mentioned above.

Pure.DI can generate builders for types derived from a base T, known at compile time.

See also:

Generics: why Pure.DI offers marker types instead of "open generics"

Classic DI containers often register "open generics" like IRepository<> → Repository<>. This is convenient, but in complex graphs, ambiguity arises: how exactly to match type arguments, especially when interfaces and implementations use different orders or names of parameters.

In Pure.DI, instead of "open generics", an approach with marker types (for example, TT, TT1, TT2) is used. This makes matching absolutely precise.

In practice, it looks like this:

using Pure.DI;

DI.Setup(nameof(Composition))
    .Bind<IRepository<TT>>().To<Repository<TT>>()
    .Bind<IDataService>().To<DataService>()
    .Root<IDataService>("Data");

var composition = new Composition();
var data = composition.Data;

interface IRepository<T>;

sealed class Repository<T> : IRepository<T>;

sealed record User;

sealed record Order;

interface IDataService;

sealed class DataService(
    IRepository<User> users,
    IRepository<Order> orders) : IDataService;

See also:

On-demand injection: Func, Lazy, and factories

Sometimes a service needs to create dependencies not immediately, but as needed:

a "heavy" dependency (driver initialization, data warming);
many instances of one type (list items, game entities);
dependencies with runtime parameters.

Pure.DI supports factory delegates (Func<T>, Func<TArg, T>, Func<TArg1, TArg2, ..., T>) and Lazy<T> out of the box.

Example: a service generates several one-time tokens, each time creating a new object:

using Pure.DI;

DI.Setup(nameof(Composition))
    .Bind<ITokenGenerator>().To<TokenGenerator>()
    .Bind<ITokenService>().To<TokenService>()
    .Root<ITokenService>("Tokens");

var composition = new Composition();
composition.Tokens.IssueBatch(3);

interface ITokenGenerator
{
    string Next();
}

sealed class TokenGenerator : ITokenGenerator
{
    public string Next() => Guid.NewGuid().ToString("N");
}

interface ITokenService
{
    void IssueBatch(int count);
}

sealed class TokenService(Func<ITokenGenerator> generatorFactory) : ITokenService
{
    public void IssueBatch(int count)
    {
        for (var i = 0; i < count; i++)
        {
            var gen = generatorFactory(); // new instance on demand
            Console.WriteLine(gen.Next());
        }
    }
}

See also:

BCL support: when standard types "just work"

In traditional containers, many tasks are solved by special extensions. In Pure.DI, a significant part of useful types from the .NET Base Class Library (BCL) is supported "out of the box".

From frequently used:

Func<T>, Func<TArg1, T>, Func<TArg1, TArg2, ..., T> — factories;
Lazy<T> — lazy creation;
IEnumerable<T>, arrays — collections of dependencies;
Task<T>, ValueTask<T> — for async roots;
IServiceProvider/Service collection scenarios (when integration with the Microsoft DI ecosystem is needed).

See also:

Decorators and interception: adding logging and metrics without rewriting code

Interception in Pure.DI in the basic variant works well with the Decorator pattern: we "wrap" the implementation in another implementation of the same interface.

Real example: wrap IOrderService in a logging decorator.

using Pure.DI;

DI.Setup(nameof(Composition))
    // "base" — base implementation
    .Bind("base").To<OrderService>()
    // Decorator uses "base"
    .Bind<IOrderService>().To<LoggingOrderService>()
    .Bind<ILogger>().To<ConsoleLogger>()
    .Root<IOrderService>("Orders");

var composition = new Composition();
composition.Orders.PlaceOrder("ORD-42");

interface ILogger
{
    void Info(string message);
}

sealed class ConsoleLogger : ILogger
{
    public void Info(string message) => Console.WriteLine(message);
}

interface IOrderService
{
    void PlaceOrder(string id);
}

sealed class OrderService : IOrderService
{
    public void PlaceOrder(string id) =>
        Console.WriteLine($"The order {id} has been placed");
}

sealed class LoggingOrderService(
    ILogger log,
    [Tag("base")] IOrderService inner) : IOrderService
{
    public void PlaceOrder(string id)
    {
        log.Info($"Starting the registration process {id}");
        inner.PlaceOrder(id);
        log.Info($"The registration has been completed {id}");
    }
}

See also:

Hints: additional generation settings that help during development

Hints are fine-tuned generator settings of "how exactly to generate code". For basic startup, it's enough to know three:

ToString: see the dependency graph

You can enable the generation of ToString(), which returns a diagram in mermaid format — convenient for review and discussing architecture.

See also:

Hint ToString: graph diagram

ThreadSafe: disable thread safety if you're sure

By default, generation takes multithreading into account. But sometimes object composition is built strictly in one thread (for example, when starting the application), and you can get slightly higher performance.

See also:

Hint ThreadSafe

OnDependencyInjection: point for "dynamic interception"

If it's necessary to centrally "track" or modify the injection process (logging, metrics, control), you can enable the generation of the partial method OnDependencyInjection.

See also:

Practical recommendations for implementing Pure.DI in a project

For successful implementation, the following sequence is recommended:

1) Define composition roots. Usually these are application "entry points": App, MainController, MessageHandler, BackgroundWorker. Minimize their number, ideally to one root.
2) Reduce object creation to composition. In other modules, let only business code and contracts remain. The fewer objects are created manually, the better.
3) Start with constructor injection. Use other types of injection as a tool for build-up and integration.
4) Use auto-binding with caution: excellent for demos, often unnecessary for good architecture.
5) Don't abuse Singleton. And if it's necessary — ensure thread safety and correct resource release. Remember about dependency capture - if a Singleton uses some dependency with a different lifetime, that dependency will also be a Singleton.
6) Don't make using Resolve() methods the main model. Composition roots are your path to clean architecture and calm updates in production environment.
7) Keep constructors simple: without heavy logic and I/O operations. This will allow you not to worry about composition size and not force you to use various tricks like delayed object creation. If necessary — use factories or separate initialization logic.
8) Don't get carried away with factories: factories are always additional logic that requires support. Use regular bindings to implementations.

Conclusion

Pure.DI makes DI predictable and transparent:

the compiler guarantees the correctness of object composition;
object creation turns into readable code;
lifetimes and tags are described declaratively;
the application remains as fast and predictable as possible.

If the idea of "Pure DI" is close to you, not "runtime DI container", Pure.DI is worth trying on at least one service or module — usually after that, it's hard to return to the "black DI box".

DEV Community: Nikolay Pianikov

Pure.DI vs. Autofac: Code Generation or a Classic DI Container?

The Short Answer

One Task, Two Architectures

Feature Matrix

Registrations, Lifetimes, and Implementation Selection

Lifetimes

Keyed Services and Tags

Generic Bindings

Generic Roots

Factories and Relationship Types

Owned<T>: Same Name, Different Implementation

Autofac Setup

Pure.DI Setup

Property and Method Injection, and Building Up Objects

Decorators and Interception

Modules and Large Compositions

Where Pure.DI Is Particularly Strong

A Graph Error Becomes a Build Error

Composition Roots

Native AOT Without Reflection in Generated Code

Modern C# Becomes Part of the Object Composition

Performance: The Overhead of a Classic DI Container

Where Autofac Is Objectively Stronger

Assembly Scanning

Registration Sources and Resolve Pipelines

Ready-Made Multitenancy Infrastructure

Different Extensibility Models

Conclusion

What's new in Pure.DI: union types, interface generation, and DI without unnecessary allocations

Part 1. New features

Union types as DI contracts

Generating interfaces from classes

Implementation-level attribute bindings

[Export]: class members as dependency sources

Custom binding attributes

Scopes: SetupScope

Platform scopes: Unity scenes and Microsoft DI

Nullable reference types end to end

TryBuildUp: safe object build-up

New C# 13/14 features: partial constructors and OverloadResolutionPriority

Part 2. Performance: DI on hot paths

Span<T> and ReadOnlySpan<T> as dependencies

Factories for stack-only values

Zero-copy parsing and method injection on a hot path

Diagnostics for stack-only values

Non-boxing union results

High-performance example catalog

Code generation optimizations

Useful extras

Conclusion

Pure.DI: DI without container, without .NET type reflection, and with compile-time validation

DI: what we are actually trying to solve

Pure DI: "no container", but dependency injection exists

What is Pure.DI — in simple terms

Why this is better than a "regular" DI container in real work

Predictable performance

Errors — at compile time, not at runtime

Clear composition roots instead of endless Resolve<T>()

Convenient for libraries and limited environments

Quick start

Composition class

Bindings: how to link interfaces with implementations

Automatic bindings: convenient, but be vigilant

Factories: when you need more than just calling a constructor

Simplified bindings: when the contract can be determined automatically

Tags: multiple implementations of one contract

Lifetimes

Composition arguments: how to pass external state without global static variables

Root arguments: when parameters are needed only at one entry point

Generation and usage: roots as properties (and why this is convenient)

Resolve methods: convenient, but it's Service Locator

Dependency injection methods

Builders (BuildUp): when it's not possible to control object creation

Generics: why Pure.DI offers marker types instead of "open generics"

On-demand injection: Func, Lazy, and factories

BCL support: when standard types "just work"

Decorators and interception: adding logging and metrics without rewriting code

Hints: additional generation settings that help during development

ToString: see the dependency graph

`Owned<T>`: Same Name, Different Implementation

`[Export]`: class members as dependency sources

Scopes: `SetupScope`

`TryBuildUp`: safe object build-up

New C# 13/14 features: partial constructors and `OverloadResolutionPriority`

`Span<T>` and `ReadOnlySpan<T>` as dependencies

Clear composition roots instead of endless `Resolve<T>()`