dotNext: a .NET library family built around not allocating

The premise is that allocation is your problem

dotNext is described as a set of powerful libraries designed for high-performance scenarios when your application expects near zero memory allocation and high flexibility, aimed at high load microservices, database engines, actors and various kinds of distributed application.

That premise explains the feature list better than the feature list explains itself. There is buffer manipulation, string building, monadic types, advanced GC notifications, and a low level API for working with memory that covers alignment detection, type safe unmanaged allocators and Span<T> manipulation. There is a streaming Base64 encoder and decoder, an async friendly SIEVE cache, async locks, and extended LINQ expression trees with dynamic code generation tools with async lambdas for metaprogramming.

The technical commitment is stated in one sentence at the end of that list, and it is the one to hold on to. All of these things are implemented in 100 percent managed code on top of the existing .NET API. There is no native component, no runtime patch and no custom allocator, which means the gains come from how you use the platform rather than from replacing it.

The project lives under the dotnet organisation, which is a reasonable signal about the level of engineering behind it, and the repository carries an AGENTS.md, a .devcontainer/, an azure-pipelines.yml and a global.json alongside the source. The licence is MIT.

One repository, a dozen NuGet packages

The packages are split by area rather than shipped as one library, and the release notes make the split legible.

DotNext itself is the core package, holding the monadic types, the buffer and string work, the memory API and the SIEVE cache. DotNext.Metaprogramming covers the expression tree and dynamic code generation work. DotNext.Unsafe is the package for the more dangerous corners, and the 6.10.0 release added an ExecutionStack with extension properties and methods for execution stack inspection to it. DotNext.Threading holds the concurrency primitives, including the async locks and the PersistentChannel, whose buffer size now defaults to the system page size.

DotNext.IO is the I/O package, and it gained FileBufferingWriter and PoolingBufferedStream with the same system page size default, plus ModernTextReader and ModernTextWriter classes with all the necessary overloads to implement text readers and writers. The cluster packages are DotNext.Net.Cluster, where the release improved the performance of the MessagingClient and MessageHandler message dispatching, and DotNext.AspNetCore.Cluster, and there is a DotNext.MaintenanceServices package on a separate 1.10.0 version line.

That versioning detail is worth noticing. The core packages are on 6.10.0 while the maintenance services package is on 1.10.0, so the family does not share a single version number, and pinning a coherent set means looking at the release notes for each package rather than assuming they move together.

The quick links section points to the feature documentation, the API documentation, a benchmarks page on the project site, and the NuGet profile that publishes them.

The cluster half: Raft, a write ahead log, TCP multiplexing and gossip

Four of the listed features are about running more than one process, and they are the part of dotNext that is genuinely hard to build.

The Raft Consensus Algorithm implementation comes with extensions such as failure detection, and it sits next to a fast general-purpose Write Ahead Log. A WAL is the boring, essential half of any replicated system, and having one that is described as general purpose rather than tied to a specific storage engine means you can put it under a database, a message queue or your own storage.

Then there is the TCP multiplexing protocol, which lets several logical streams share one connection, and the HyParView protocol implementation, which is a gossip style membership protocol. HyParView is designed for large scale membership with low overhead, and the fact that it is here suggests the cluster components are aimed at systems with many nodes rather than a three node Raft group in a Kubernetes cluster.

The honest way to read this section is that dotNext offers building blocks for distributed systems, not a distributed system. A Raft implementation with failure detection still needs a membership model, a state machine, a snapshot strategy and an operational story, and choosing to assemble those yourself is a real cost that the library's existence does not remove.

The AI agent skills are the easiest thing to install

The 10-13-2026 release adds Agent Skills that teach coding agents how to use the libraries efficiently, and the install instructions are short enough to try in a minute.

For Claude Code, the marketplace is added and the skill pack installed.

/plugin marketplace add dotnet/dotNext
/plugin install dotnext-skills@dotnext

For Codex the same two steps with a different tool name.

codex plugin marketplace add dotnet/dotNext
codex plugin add dotnext-skills@dotnext

And for any agent that supports Agent Skills, there is a single command.

npx skills add dotnet/dotNext

There is also a manual route. The skill folders live in ai/plugins/dotnext-skills/skills in the repository, and you can copy them into the skills directory your agent reads, for example .claude/skills/ for Claude Code, or .agents/skills/ for Codex and GitHub Copilot.

What the skills cover tells you what the library expects from its users. dotnext-core covers the Optional and Result monads, timestamps, type maps and console app lifetime. dotnext-threading covers asynchronous programming and async locks. dotnext-concurrency covers the concurrent data structures. dotnext-memory covers the allocation-free memory routines, buffer writers and memory pooling. In other words, the skills are teaching an agent how to avoid allocations, which is the same discipline the library is built around.

Semantic versioning with a support matrix that says no to most versions

The libraries are versioned according to Semantic Versioning 2.0, and the support policy table is unusually blunt about what is alive.

The 0.x, 1.x, 2.x, 3.x and 4.x lines are all marked unsupported. The 3.x line targeted .NET Standard 2.1 and .NET 5, the 4.x line targeted .NET 6, and the 5.x line targets .NET 8 and is marked as receiving bug and security fixes only. The 6.x line targets .NET 10 and is the one marked for active development.

So a team on .NET 8 is on the 5.x line, which means no new features, and a team that wants the current work needs .NET 10. That is a meaningful constraint for adoption and it is stated in one table rather than buried, which is the right way to state it.

The development philosophy behind that table is short and worth reading. The libraries are available for various .NET form factors, namely Mono, WASM and NativeAOT. There is a minimal set of dependencies. And there is a high quality of documentation as a goal.

The NativeAOT mention in particular interacts with the managed-only design in a useful way. A library that allocates nothing and uses no reflection-heavy paths is exactly what NativeAOT needs, and the fact that the project lists it as a target form factor suggests the low allocation work was done with that in mind rather than as an afterthought.

What 6.10.0 tells you about where the effort goes

The release notes for 10-13-2026 are short, and the details are all about removing overhead from common operations.

In the core package, interpolation string handlers do not box enum values any more, and Optional<T> and the other monadic types do not box the underlying value on a ToString call. A static extension method was added for on-stack string interpolation that does not convert the result to a string at all, so it can be consumed as a ReadOnlySpan<char> instead. CompositeFormat interning was added, so the IsInterned or Of static extensions can return an already parsed template, and a conversion from TypedReference to the Variant data type was added.

Those four changes are the same theme stated four ways. Boxing a value or parsing a format string that has already been parsed is a small cost in isolation, and a real cost when it happens on every log line, every metrics sample or every serialization call in a hot loop. A library whose stated purpose is near zero allocation spends its release notes on exactly these places.

The other packages show the same attention to the edges. The ExecutionStack addition to DotNext.Unsafe is inspection tooling for the unsafe corners. The PersistentChannel and the file buffering writers now take the system page size as their default buffer size, which is the kind of change that only matters on a specific platform and only shows up in a profile, and the ModernTextReader and ModernTextWriter classes exist so that the text I/O path does not fall back to the older implementations.

Where this library set is the wrong answer

The first boundary is the platform. The actively developed line targets .NET 10, which means a team on an older runtime is on a line that only receives fixes, and a team whose organisation is still standardising on .NET 8 is signing up to be a version behind. The features are also written in a style, the monadic Optional and Result types and the allocation-free string building, that pays off only if the code base is written that way. Adopting the libraries in a project that is not willing to change its habits gives you extra types and no allocation win.

The second boundary is the cluster components. Raft with failure detection, a write ahead log, TCP multiplexing and HyParView are serious infrastructure pieces. Assembling them into a correct distributed system is a project, and the fact that they are available as libraries does not make the project smaller. A team that needs one writer and three readers is better served by a database that already does this.

The third boundary is the managed-only rule. If your performance problem is in native code, in a database engine's own storage layer, or in an interop path where the allocation is not yours to control, a library that avoids managed allocations will not move the number.

And the last one is ordinary maintenance. MIT licensing and an active 6.x line mean the code is safe to build on, but this is a collection of many small libraries with many surfaces, and each one you take on is a dependency whose future you now track.

Editorial conclusion

dotNext fits a .NET team building a high load service, a database engine or an actor system where the garbage collector shows up in a profile and the team is willing to change how it writes code, since the whole library set is organised around avoiding allocation rather than making it cheap. It does not fit a team on .NET 8 who wants the current feature line, because the 6.x packages target .NET 10 while 5.x is limited to bug and security fixes, and it does not fit a project that needs native or unmanaged code paths, since everything here is 100 percent managed. Verify three things before you adopt it: which package actually holds the feature you need, because the family is split across DotNext, DotNext.IO, DotNext.Threading, DotNext.Unsafe, DotNext.Net.Cluster and the rest, the .NET version your target framework allows, and whether the cluster components are a Raft implementation you are willing to operate, since the failure detection extensions and the write ahead log come with that responsibility.

Frequently asked questions

Official sources

1. dotnet/dotNext on GitHub
2. Issues
3. License: MIT
4. Project website
5. README