Dock Avalonia Layout System: Setup and Architecture

Dock's document workspace model

Dock addresses a specific desktop interface problem: applications modeled around multiple documents and tools need to open, close, select, move, and restore workspace elements without manually rebuilding the interface for every operation. It targets developers creating Avalonia applications that resemble an editor, IDE, dashboard shell, or another multi-window workspace. A conventional fixed layout can be simpler for an application with one view and a few buttons, but it does not provide the same document-centric workspace behavior.

The README identifies `ItemsSource` binding as a central path for managing document collections through `DocumentDock`. This is useful when the open-document list is application state rather than a set of controls created only in XAML. Dock also offers `DocumentTemplate` for controlling how document content is rendered. Together, those features separate the collection of open documents from the visual presentation of an individual document, which matters for applications following MVVM.

The intended users are Avalonia developers, not teams looking for a platform-neutral docking engine. Dock is coupled to Avalonia controls, XAML integration, and .NET package distribution. Its packages also divide optional concerns, including MVVM integration, serialization, themes, diagnostics, and specialized controls. That modularity lets an application start with the main integration and add only the components its design requires.

Dock layout movement, floating windows, and templates

Dock's layout system composes documents, tools, panels, tab strips, hosts, and floating windows. The repository includes samples dedicated to control panels, external tab strips, window relations, workspaces, and Office-style layouts. This indicates that docking behavior is central rather than a single visual control with limited tab support. The `DockOfficeSample` and `DockControlPanelsSample` directories provide project-specific references for applications seeking a conventional desktop-office workspace.

`ItemsSource` support lets an application bind a document collection directly to `DocumentDock` instead of manually synchronizing every tab. `DocumentTemplate` supplies the rendering hook for document content. The Fluent, Simple, and Browser theme packages provide separate visual choices rather than forcing every application into one control appearance. The README also states that Fluent supports customization, although it does not enumerate every customizable property or theme resource.

Floating windows belong to the same layout system. According to the README, documents and tools can be detached into separate windows. This makes Dock relevant when workspace arrangement is user state that should survive application sessions, rather than decoration confined to one fixed window.

The sample directories show several integration paths: code-only MVVM, INPC, Prism, ReactiveProperty, ReactiveUI, dependency injection, and managed controls. That breadth is useful for teams with established patterns, but it does not mean every sample implements the same application architecture. Separate projects exist for canonical ReactiveUI, routing, managed controls, and dependency injection, so developers should treat those samples as distinct implementation examples rather than interchangeable configurations.

Dock serialization for saved application layouts

The README documents four serialization formats: JSON, XML, YAML, and Protobuf. This addresses persistence of docking layouts, allowing an application to save its workspace arrangement and restore it later. The installation example includes `Dock.Serializer.Newtonsoft`, but the README does not map every listed format to a separate NuGet package.

That distinction matters during adoption. A team that selects Dock because layout persistence is required still needs to determine which serializer package it needs and how its application stores and loads `Dock.Model` objects. The README confirms the format choices, but it does not document migration rules between versions, schema compatibility guarantees, or a rollback procedure for persisted layouts.

Serialization also changes upgrade work. An application that writes layouts may retain data containing model types that change between Dock releases. The README states that libraries target `net6.0`, `net8.0`, and `net10.0`, while the recent release list includes `v12.1.0.7`, `v12.1.0.8`, and `v12.1.0.9`. Those entries establish recent version movement, but they do not promise that every saved layout remains readable across releases. Engineers adopting persistence should inspect the serializer source and release notes for the exact package versions they plan to combine.

Dock content caching and deferred materialization

Dock offers two separate controls for content cost. The `CacheDocumentTabContent` theme option can keep document views alive across tab switches. According to the README, this avoids losing a live view when the user returns to a previously selected tab. The trade-off is that retained views may also keep view state and associated resources in memory while inactive. The README names the option but does not provide lifecycle measurements or an explicit eviction policy.

The separate `Dock.Controls.DeferredContentControl` package addresses presentation timing rather than retention. The README states that expensive content presenter work can be deferred through shared or scoped timelines, a per-host delay, and explicit ordering. This gives application code more control over when content is materialized. The documentation does not describe it as a general background computation system, and its stated scope remains control presentation.

These controls answer different questions. `CacheDocumentTabContent` determines whether a document view remains alive. Deferred materialization determines when content presenter work occurs. An application may need only one, both, or neither. The repository includes `samples/DockDeferredContentSample/` for the deferred path. The separate `samples/BrowserTabTheme/` directory represents a browser-tab theme sample rather than evidence that every Dock application needs deferred loading.

Installing Dock and building the first target

NuGet is the documented distribution route for application use. The following PowerShell example comes from the README and installs the main Avalonia integration, an MVVM package, the Newtonsoft serializer, two theme packages, and the deferred-content control. It is a documented package example, not a mandatory bundle for every application.

Install-Package Dock.Avalonia
Install-Package Dock.Model.Mvvm
Install-Package Dock.Serializer.Newtonsoft
Install-Package Dock.Avalonia.Themes.Fluent
Install-Package Dock.Avalonia.Themes.Browser
Install-Package Dock.Controls.DeferredContentControl

For a source-level build, clone the repository and build the main Avalonia project for `net10.0` in the `Release` configuration:

git clone https://github.com/wieslawsoltes/Dock.git
dotnet build src/Dock.Avalonia/Dock.Avalonia.csproj -c Release -f net10.0

The README states that the libraries multi-target `net6.0`, `net8.0`, and `net10.0`, while samples target `net10.0` unless noted otherwise. A successful command should compile `Dock.Avalonia` for the selected framework, although the README does not include expected console output.

Developers who need the repository-wide restore, build, and test path can use the documented Unix script:

./build.sh

On Windows, the README names `build.cmd` as the alternative and says the scripts work on Windows and Unix-like systems. It does not provide a minimal XAML startup example. The first application integration therefore needs an existing Avalonia host and a suitable repository example, such as `DockQuickStartSample` or a sample matching the chosen MVVM framework.

Dock package boundaries and framework constraints

Dock is split across packages for controls, diagnostics, themes, markup extensions, serializers, model integrations, and optional UI components. The documented `Dock.Avalonia` package provides the primary integration. Narrower packages include `Dock.Avalonia.Diagnostics`, `Dock.Avalonia.Themes.Fluent`, `Dock.Avalonia.Themes.Browser`, `Dock.Avalonia.Themes.Simple`, `Dock.Controls.DeferredContentControl`, and `Dock.Controls.ProportionalStackPanel`.

The README claims support for ReactiveUI, Prism, ReactiveProperty, and standard MVVM patterns, along with .NET dependency injection support. These claims matter because a docking library coordinates controls, documents, windows, and application services. The examples show, however, that integration is not uniform. ReactiveUI appears in canonical, routing, managed, window-relations, workspace, dependency-injection, and code-only variants. Prism and ReactiveProperty have focused samples. A team should inspect the sample closest to its production architecture rather than assuming a package adapter removes framework-specific design work.

The platform boundary is equally clear. Dock is described as a docking layout system for Avalonia, and its build documentation names .NET target frameworks. The README does not present it as a reusable engine for WPF, WinUI, JavaScript, mobile, or web interfaces. This boundary matters when choosing Dock because a reusable word such as "docking" does not imply support outside Avalonia.

Dock alternatives, releases, and upgrade boundaries

The practical alternative for a static application is a layout built from ordinary Avalonia containers and application-specific state. That approach can fit a single-window utility, a wizard, or a form with fixed regions. It avoids introducing a docking model when users cannot rearrange or restore the workspace. Dock takes a different approach by modeling documents, floating windows, templates, panels, and serialized layouts. Its added structure becomes relevant when workspace arrangement is user-controlled state, but that same structure increases the integration surface.

Dock is not archived. Its last push was on 2026-10-14, and the release list includes `v12.1.0.9` dated 2026-10-13, `v12.1.0.8` dated 2026-10-12, and `v12.1.0.7` dated 2026-10-05. This documents recent development, but it does not prove that every upgrade has a low cost. An application combining floating windows, ReactiveUI routing, persisted layouts, custom themes, and deferred content presents a different compatibility surface from a basic document shell.

The README does not publish a formal upgrade policy, migration guide, serializer compatibility matrix, or layout rollback procedure. Projects should therefore review saved-layout compatibility and package alignment during each Dock version change. Dock is governed by the MIT License according to the README, and the repository contains `LICENSE.TXT`. Teams still need to read that file for the applicable license terms rather than infer compliance from the package metadata alone.

Editorial conclusion

Developers building Avalonia applications with persistent, movable document and tool areas should evaluate Dock, especially when layout serialization, floating windows, or support for several MVVM frameworks matters. Fixed, static applications should avoid its added control and model structure. Before adoption, verify the required Avalonia target, theme, serializer, MVVM integration, caching behavior, and persisted-layout compatibility against the selected Dock version.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. wieslawsoltes/Dock on GitHub