DryIoc: a small, fast IoC container for .NET

What the container is for

DryIoc is an inversion of control container for .NET, and the design goal in the README is stated in three words: low ceremony, performance and extensibility. That means it is aimed at a developer who wants to construct an object graph with constructor injection without learning a framework's conventions, and who does not want the container to own the application. The project is not new, it has a Stack Overflow tag, a Slack workspace, a Gitter room and a long history of release notes, and it is also the kind of library that gets adopted sideways through a framework. The topics carry Prism and Xamarin, and the documentation is generated from the source with a purpose-built tool, which tells you the project treats its own documentation as a deliverable. What you get is a container and a set of companion packages, and nothing else.

Three packages, three different contracts

The NuGet packaging is unusual and worth understanding before you install anything. There is DryIoc.dll, the normal binary distribution, and it is the one that carries the compile-time dependency injection support. There is DryIoc, which is the source code package, so the code is compiled into your assembly rather than referenced as a separate binary, which matters for trimming, for obfuscation and for a build that wants everything in one place. There is DryIoc.Internal, the same source with the public types made internal, which is the variant for a team that does not want the container's API leaking into its own public surface. A fourth package, DryIoc.MefAttributedModel, provides the attributed model for the Managed Extensibility Framework, so a project that already has MEF components can have them resolved rather than rewritten. Choosing between them is not a preference, it changes the public surface of your assembly.

Compile-time DI and the T4 workflow

The feature that distinguishes the DryIoc.dll package is that the container can be generated instead of reflected. On the first build, the package scaffolds T4 templates into the project, and running the template tool emits a generated container source file, called Container.Generated.cs, which resolves the graph without reflection and is therefore friendly to ahead-of-time compilation and to trimmed deployments. The command is short:

dotnet t4

and the build that scaffolds the templates is an ordinary one:

dotnet build

The repository ships a working example of the whole path, a sample named MinimalWeb that shows the generated container used with an ASP.NET minimal API, plus a separate test project for it. The trade-off is straightforward. Reflection based resolution keeps the container configuration in one place and needs no code generation step, while the generated approach moves the cost to build time, which means every change to a registration has to be recompiled and every developer and every build agent needs the template step in place.

The benchmark table and what it measures

The README carries a benchmark with a defined scenario, a cold start in which services are registered, a scope is opened and a root scoped service is resolved for the first time, using a unit of work scope and an object graph of forty dependencies four levels deep. The environment is stated as well, BenchmarkDotNet on Windows 11 with an Intel Core i9 and the .NET 9 SDK. In the current table the mean for DryIoc is 65.70 microseconds with 32.74 kilobytes allocated, the built-in Microsoft container is at 81.25 microseconds and 91.15 kilobytes, the DryIoc adapter for that container is slower still, Autofac is at 323.50 microseconds, and the Lamar and Grace adapters are in the milliseconds. Two caveats are worth holding on to. The table compares DryIoc 6.0.0, which is ahead of the published 5.4.3 tag, and it measures a cold start rather than steady state resolution, so it says more about first-request latency than about a container that is already warm.

Target frameworks and the build system

The package targets five frameworks, the .NET Framework 4.7.2, .NET Standard 2.1, .NET 8, .NET 10 and .NET 11, which is a broad spread for a library that is otherwise very focused. The repository itself is a large solution with the source, the test suite, a system under test folder, the samples, the documentation, a legacy folder, a playground and a set of package specification files, and it carries shared build properties and targets files that configure the whole tree at once. Continuous integration runs on GitHub Actions with a CI workflow, and an AppVeyor configuration is also present, which is the arrangement for projects that still build packages on Windows. The batch files in the root, of which there are a dozen, are the convenience scripts for building the solution, the benchmarks, the documentation and the different flavour of build, and they are a sign of how the project actually gets worked on day to day.

Where DryIoc is the wrong choice

There are three honest limits. The first is that it is only a container. It resolves objects, it does not host them, it does not read configuration, it does not build a request pipeline and it does not manage the lifetime of your application, so a team wanting all of that in one package should look at a framework rather than a container. The second is the compile-time path, which trades flexibility for start-up cost in the wrong direction for some projects. A generated container means the object graph is fixed at build time, so anything that varies at run time, which in .NET often means configuration-driven registrations, has to be handled outside the generated code, and the build needs the template step to run reliably on every machine. The third is the source package, which is elegant for trimming and awkward for a team with a strict dependency policy, since the container's code is now inside your own assembly.

The pieces that were spun out, and the licence

Two parts of DryIoc used to live inside it and are now separate projects, which is worth knowing if you are following issues or reading older code. The expression compiler that DryIoc uses to build its runtime resolvers is now the FastExpressionCompiler project, and ImTools is a separate project under the same author. The ecosystem is also larger than the core, with a separate document listing the extensions and companion packages, so the practical question of which additional package to install is answered in the repository rather than in a forum thread. DryIoc itself is released under the MIT licence, with the terms in the licence file at the repository root, and the shared build targets sign the assemblies with a key that sits in the same tree.

Which version you are actually installing

The release list is the one place where the project is genuinely confusing, and a reader should know it before they plan an upgrade. The published tags are v5.4.3 from 2023-11-12, v5.4.2 from October 2023 and v5.4.1 from June 2023, all described as bug fix releases, and the last push to the branch was on 2026-10-18. The benchmark, meanwhile, is labelled with DryIoc 6.0.0, which is a version that exists on the branch but not as a release. The repository offers pre-release packages built by continuous integration, downloadable from the artefacts of the latest run, which is the Windows job's packages artefact, so a developer can test the 6.0 line without waiting for a tag. The version history document in the documentation directory is the place to check what changed, and the release notes on the releases page cover the stable line.

Editorial conclusion

DryIoc fits a .NET team that wants dependency injection without adopting a hosting framework, that cares about cold start and allocation on a service with many small scopes, or that needs to remove reflection from the container for an ahead-of-time compiled deployment. It does not fit a team that wants one component to give them hosting, configuration and a pipeline as well, because the container deliberately does none of that. Before adopting it, read the version history carefully, because the published tags are on the 5.x line while the branch and the benchmark already run 6.0.0, and try the MinimalWeb sample with the compile-time path before committing a build pipeline to T4.

Frequently asked questions

Official sources

1. dadhi/DryIoc on GitHub
2. Issues
3. License: MIT
4. README
5. Releases