DryIoc Documentation

DryIoc is a high-performance IoC container for .NET that provides extensive capabilities for dependency management. Key features include:

• Registration Management: Map services to implementation types, including support for registering once, replacing, or removing registrations. You can also register delegate factories, existing service instances, or perform batch registrations from assemblies.
• Service Identification: Use service keys of any type to identify registrations, allowing multiple non-keyed implementations for a single service.
• Advanced Injection: Supports constructor parameter injection, optional property/field injection, and injection into existing objects. It also supports static and instance factory methods.
• Open Generics: Full support for open-generics, including type constraints, variance, and complex nesting.
• Service Lifetimes: Control service lifetime via Reuse and lifetime scoping, including nested disposable scopes, ambient scope context, and various Reuse types like Transient, Singleton, and Scoped (with support for scoping to specific service ancestors).
• Decorators and Wrappers:
  • Decorators: Supports nested decorators with relative order control, generic/non-generic decorators, and decorators with different Reuse settings than the decorated service.
  • Wrappers: Supports service collections (T[], IEnumerable<T>, LazyEnumerable<T>, ICollection<T>), single service wrappers (Lazy<T>, Func<T>, Meta<TMetadata, T>, Tuple<TMetadata, T>, KeyValuePair<TKey, T>), and parameter currying via Func<TArg, T>.

You can use Made.Of to provide a predicate that selects a constructor or factory method dynamically based on the current resolution context. The predicate receives a request object (req) which provides information about the resolution process.

Common properties of the request object include:

• req.IsResolutionRoot: True if the service is being resolved directly (not as a dependency of another service).
• req.Parent: A collection of services that are currently being resolved as part of the parent object graph. You can inspect these to check for specific ServiceKey values or types.

This is useful for implementing complex logic where the instantiation strategy changes depending on whether the service is a top-level dependency or part of a specific parent's graph.

c.Register<IFoo>(made: Made.Of(req =>
{
    // If being injected into a parent with a specific service key
    if (req.Parent.Any(p => "special".Equals(p.ServiceKey)))
        return typeof(Consumer).GetMethod(nameof(Consumer.GetMyFoo), BindingFlags.Public | BindingFlags.Static);

    // If being resolved as a root
    if (req.IsResolutionRoot)
        return typeof(Foo).GetConstructors().FirstOrDefault(c => c.GetParameters().Length == 0);

    // Default fallback
    return typeof(Foo).GetConstructors().First(c => c.GetParameters().Any(p => p.ParameterType == typeof(FooNameProvider)));
}));

When calling container.Resolve<X>() for a non-singleton service, DryIoc follows a multi-stage lifecycle to balance initial speed with subsequent performance:

1. First Call (Discovery & Interpretation): DryIoc discovers and constructs the expression tree for the object graph of X. It then interprets this expression to obtain the service. This interpreted expression is then cached.
2. Second Call (Compilation & Replacement): DryIoc finds the cached expression, compiles it into a high-performance delegate, replaces the cached expression with this delegate, and then invokes it.
3. Third Call (Invocation): DryIoc finds the cached delegate and invokes it directly.

Note on Singletons: Singletons are always interpreted rather than compiled because they are created once, and one-time interpretation is faster than the overhead of compilation plus invocation. They are injected as ConstantExpression unless wrapped in Func or Lazy wrappers.

A Wrapper in DryIoc is a data structure that operates on one or more registered services. They allow you to change how a service is provided to a consumer (e.g., delaying instantiation or providing multiple implementations).

Wrappers fall into two categories:

1. Open-generic types: These use a generic argument to identify the service type being wrapped. Examples include Func<TService>, Lazy<TService>, and IEnumerable<TService>. Note that an open-generic wrapper with multiple type arguments (like Func<TArg0, TArg1, TService>) wraps exactly one service type (TService).
2. Non-generic types: The wrapped service is identified via the RequiredServiceType. An example is LambdaExpression.

Key Rules:

• Nesting: Wrappers are composable (e.g., IEnumerable<Lazy<TService>>).
• Overriding: If you explicitly register a wrapper type (like Func<>) as a normal service, it will override the default wrapper behavior.
• Single Service Limit: A single wrapper cannot wrap multiple different service types simultaneously.

// Example of a class using a wrapper in its constructor
class B
{
    public B(Lazy<A> a) { }
}

// Usage in container
var container = new Container();
container.Register<A>();
container.Register<B>();

// Lazy is available without explicit registration of the wrapper itself!
var b = container.Resolve<B>();

When resolving a collection of generic types (e.g., using ResolveMany<T>()), DryIoc includes variance-compatible types by default. For example, if IHandler<out T> is covariant, resolving IHandler<A> will return implementations of IHandler<B> where B is a subtype of A.

If you want to disable this behavior and only receive exact matches, configure the container with rules.WithoutVariantGenericTypesInResolvedCollection().

// Default behavior: includes variance-compatible types
var container = new Container();
container.Register<IHandler<A>, AHandler>();
container.Register<IHandler<B>, BHandler>();

var aHandlers = container.ResolveMany<IHandler<A>>();
// Result contains both AHandler and BHandler if IHandler is covariant

// To disable variance matching:
var containerStrict = new Container(rules =>
    rules.WithoutVariantGenericTypesInResolvedCollection());

var aHandlersStrict = containerStrict.ResolveMany<IHandler<A>>();
// Result contains only AHandler