AvalonDock 5 adopts a modular WPF package architecture

A docking container borrowed from IDE layouts

AvalonDock is described as a WPF Document and Tool Window layout container that arranges documents and tool windows the way well known IDEs do, and the README names Visual Studio, Eclipse and JetBrains Rider as the models. If your application is a code editor, a designer, a query tool or anything else with a document area and a set of auxiliaries, that is the layout problem this library solves.

The control that anchors everything is DockingManager, which the README names as the main entry point for using AvalonDock in a WPF application and the provider of the core docking functionality.

The repository itself is a source tree rather than a single project: source/ holds the code, docs/ the documentation, and there are separate AGENTS.md and CONTRIBUTING.md files at the root, plus a LICENSE file carrying the MS-PL identifier. The GitHub Actions workflow for releases carries a CI badge, so tagged releases are produced by automation rather than by hand.

Version 5 is the current line and the README attributes three things to it: first-class MVVM support, dependency injection integration and a modular package architecture. That third item is the one that changes existing projects, because it is a packaging decision rather than an API addition.

The package split, and which one you actually need

The NuGet list is organised into three groups and it is worth reading as a dependency map.

The core group has Dirkster.AvalonDock as the main WPF docking framework package, Dirkster.AvalonDock.Core as UI-agnostic interfaces and models, Dirkster.AvalonDock.Mvvm for MVVM base classes with no external dependencies, Dirkster.AvalonDock.Mvvm.CommunityToolkit for CommunityToolkit.Mvvm integration with [ObservableProperty] support, and Dirkster.AvalonDock.DependencyInjection with IServiceCollection extensions for registration.

The named MVVM types are specific: DockableBase, ToolboxBase and DockLayoutService in the base package, and ObservableDockableBase plus ObservableToolboxBase in the CommunityToolkit one. That split lets a project adopt the MVVM layer without taking a dependency on CommunityToolkit.Mvvm, which matters if your application already has its own notification framework.

The serializers group has Dirkster.AvalonDock.Serializer.Xml for XML layout serialization and Dirkster.AvalonDock.Serializer.Json for JSON, and the JSON package is the one the README marks as new in v5. Layout persistence is the feature that makes a docking framework feel like a real IDE, so this is the group most worth testing on day one rather than assuming.

The quick start shows the shape of a typical reference set.

dotnet add package Dirkster.AvalonDock
dotnet add package Dirkster.AvalonDock.Mvvm
dotnet add package Dirkster.AvalonDock.Mvvm.CommunityToolkit  # optional, for [ObservableProperty] support
dotnet add package Dirkster.AvalonDock.DependencyInjection
dotnet add package Dirkster.AvalonDock.Themes.Arc

Five packages, one of them optional. Nothing in that list pulls in the serializers, which means layout saving is a decision rather than a default.

Themes ship as separate packages too

The theme group is the widest part of the catalogue and tells you something about how the project treats appearance. Every theme is its own package.

dotnet add package Dirkster.AvalonDock.Themes.Arc

Seven themes are listed. Arc is marked NEW. Aero, Expression and Metro are the Windows-era themes that carried the library through its earlier versions. Dirkster.AvalonDock.Themes.VS covers the Visual Studio themes for 2015 and 2022 and includes .vstheme support, which is the one that lets the docking chrome follow the user's own Visual Studio theme. Dirkster.AvalonDock.Themes.VS2010 and Dirkster.AvalonDock.Themes.VS2013 are both marked Legacy.

The consequence for a maintainer is that a theme change is a version bump of a different package than the docking logic. That keeps the dependency graph honest and makes each artifact independently adoptable, at the cost of tracking several versions when you upgrade.

Arc being new and unmarked with a version date is worth noticing against the release history: v4.74.1 shipped on 2026-04-25, v5.0.0 on 2026-08-12 and v5.0.1 on 2026-10-04, so the theme and the JSON serializer arrived in the same period as the packaging change.

Who runs it in production

The README lists the projects that use the library, and they are a reasonable sample of what kind of application it suits. Stride, a cross-platform C# game engine, is the most demanding user. Optick, a C++ profiler for games, uses the tool layout. RoslynPad is a cross-platform C# editor built on Roslyn and AvalonEdit, which is the closest analogue to a docking IDE. WpfDesigner is the WPF designer from SharpDevelop. DaxStudio is a DAX query tool for Power BI and Analysis Services. Macad3D is an open source 3D construction tool. Edi is an open source text editor IDE built on AvalonDock and AvalonEdit. Profile Explorer is a Microsoft CPU profiling trace viewer.

Two patterns stand out. Several of them pair AvalonDock with AvalonEdit, which suggests that the document-editing story is a common pairing rather than a coincidence. And the list spans commercial and open source products, which tells you the MS-PL licensing has not been a barrier for either.

The boundaries worth knowing before you start

WPF is the hard boundary. The framework badges in the README cover .NET Framework 4.8, .NET 9 and .NET 10, so a modern .NET desktop application is covered and nothing else is. If your team is on a cross-platform stack or a browser, there is no path here.

A second boundary is that the library arranges windows; it does not give you the content. AvalonDock supplies the docking, the tabs, the panes and the layout model. Your documents and tools are your own types, and the MVVM base classes tell you how to expose them as dockables. Teams expecting a full IDE shell with file browsers, tool windows for every subsystem and a command palette will build that part themselves, which is normal for a layout container but worth stating.

The third is the upgrade surface created by version 5. A project that referenced a single package before and now assembles five has to make package decisions, and anything that reads or writes layouts has to decide between the XML and the new JSON serializer. The README documents the packages and points to a wiki and a documentation site for tutorials and API reference, but the migration detail for a 4.x to 5.x move is not in the README itself.

Editorial conclusion

Adopt AvalonDock if you are building a WPF desktop tool whose interface needs document tabs, dockable tool windows and a persisted layout, and you want first-class MVVM types instead of the command pattern bolted on by the host application. Do not adopt it for a .NET application without a Windows desktop target, since it is WPF-only and the badges stop at .NET Framework 4.8 and .NET 9 and 10. Verify first which packages your project actually needs, because the core interface package and the main package overlap and version 5 is new enough that serializer and MVVM APIs may still be settling, with v5.0.0 dated 2026-08-12 and v5.0.1 on 2026-10-04. If layout persistence matters, test the JSON serializer before committing, since it is the piece marked as new in v5.

Frequently asked questions

Official sources

1. Dirkster99/AvalonDock on GitHub
2. Issues
3. License: MS-PL
4. README
5. Releases