ModernWpf: Fluent styles and WinUI-style controls on the WPF runtime

The gap ModernWpf fills between stock WPF and WinUI

WPF still ships the layout, input and XAML stack that desktop .NET applications are built on, but its default control styling has not kept pace with the Fluent look used elsewhere on Windows. Rewriting an application in WinUI is not an option for teams with a large WPF codebase, and hand-restyling every control template is weeks of work that has to be redone whenever a control is added. ModernWpf targets that gap. It is an independent, community-maintained library that runs directly on WPF and does not replace the WPF runtime, so existing code keeps working underneath the new templates.

The README lists what it provides: Fluent styling for stock WPF controls across Light, Dark, High Contrast and compact-resource behavior; WPF ports of modern controls including NavigationView, NumberBox, ContentDialog, InfoBar, CommandBarFlyout and ItemsRepeater; theme APIs at application, window and element level; and modern window chrome with title-bar integration. The audience is the team that has a shipping WPF application and wants the current Windows look without a framework migration. The project states it is not affiliated with or endorsed by Microsoft, which matters if your procurement process expects a vendor relationship.

How the resource dictionaries and control ports fit together

ModernWpf is consumed as XAML resources plus a control library, not as a runtime that intercepts your application. You merge two dictionaries into Application.Resources: ThemeResources, which supplies the theme API surface, and FluentControlsResources, which supplies the control templates. After that, stock WPF controls pick up the new styles because the dictionaries override the implicit styles those controls resolve at load time.

The split between stock styling and additional controls is deliberate. According to the README's upstream table, the WPF runtime, XAML, layout and input behavior stay with dotnet/wpf, and ModernWpf preserves WPF behavior there. Stock control styling comes from official WPF Fluent resources on net10.0-windows7.0 and from a compatible ModernWPF backport on the older supported targets. The extra controls come from microsoft-ui-xaml, where ModernWpf ports current WinUI control APIs and behavior for cases where WPF has no equivalent, documenting the adaptations WPF forces.

That means the same application can behave differently depending on target framework. On net10.0-windows7.0 the stock controls come from PresentationFramework.Fluent; on net462 and net8.0-windows7.0 they come from the backport. If you multi-target, you are testing two styling paths even though your XAML is identical. The README also notes a staged migration option: applications may temporarily keep ThemeResources plus XamlControlsResources, though new applications should use the recommended pair.

Installing ModernWpfUI and styling a first window

The package is named ModernWpfUI even though the product, repository and namespaces are ModernWpf. The README tells you to install an explicit 1.x version, because NuGet would otherwise resolve a frozen 0.9.x package. The command below pins the release candidate:

dotnet add package ModernWpfUI --version 1.0.0-rc.1

If that preview is not yet listed on NuGet, the README points to a validated workflow artifact or to building the repository from source. Next, merge the two recommended dictionaries in App.xaml. The ui namespace maps to http://schemas.modernwpf.com/2019:

<Application
    ...
    xmlns:ui="http://schemas.modernwpf.com/2019">
    <Application.Resources>
        <ResourceDictionary>
            <ResourceDictionary.MergedDictionaries>
                <ui:ThemeResources />
                <ui:FluentControlsResources UseCompactResources="False" />
            </ResourceDictionary.MergedDictionaries>
        </ResourceDictionary>
    </Application.Resources>
</Application>

With the resources in place, opt a window into the modern chrome and use the controls from the same namespace. WindowHelper.UseModernWindowStyle is the attached property that turns on the window styling, and the accent button comes from a named style rather than a different control type:

<Window
    ...
    xmlns:ui="http://schemas.modernwpf.com/2019"
    ui:WindowHelper.UseModernWindowStyle="True">
    <ui:StackPanelEx Margin="24" Spacing="12">
        <TextBlock
            Text="ModernWPF"
            Style="{StaticResource HeaderTextBlockStyle}" />
        <Button Content="Standard button" />
        <Button
            Content="Accent button"
            Style="{StaticResource AccentButtonStyle}" />
    </ui:StackPanelEx>
</Window>

What you should see is a window with modern chrome, a header-styled TextBlock, and two buttons where the second uses the accent brush. The repository's own interactive catalog is ModernWpf.Gallery. The README gives these commands, which restore the gallery project and then run it against net10.0-windows7.0 in Debug without restoring again:

dotnet restore .\ModernWpf.Gallery\ModernWpf.Gallery.csproj
dotnet run --project .\ModernWpf.Gallery\ModernWpf.Gallery.csproj `
    --configuration Debug `
    --framework net10.0-windows7.0 `
    --no-restore

The README notes you can substitute net8.0-windows7.0 to exercise that target instead, and that the gallery is a project sample rather than Microsoft's official WPF or WinUI Gallery.

The 0.9.x freeze is the limitation that decides adoption

The most consequential constraint is versioning, not styling. The README states that ModernWPF 1.x is the active preview line and that 0.9.x is frozen and unsupported, with no maintenance updates, security fixes or new 0.9.x releases planned. Source and binary compatibility with 0.9.x is not promised. If your application references an older package and you upgrade, you are running a migration, not a patch.

The migration guide at docs/migrating-from-0.9.md is said to cover target framework changes, resource entries, renamed APIs, and the removal of the MahApps adapter from 1.x. That last item is the sharpest edge: applications that relied on the adapter have no drop-in path in 1.x, and the README does not describe a replacement. Retired package assets for net45, netcoreapp3.0 and net5.0-windows are also gone from the 1.x line, so a project still targeting one of those frameworks cannot move to 1.x without retargeting first.

Second, 1.x is a preview line. The releases available are candidates and previews, and the README describes the roadmap as carrying source-audited feature previews through an API-frozen release candidate before stable 1.0.0 establishes the SemVer boundary. Until that boundary exists, pinning an exact version is the only sane approach, and the README itself tells you to install an explicit version rather than letting NuGet choose. Teams that require a stable, supported dependency should treat this as the wrong tool for now, or stay on 0.9.x and accept that it receives nothing.

ModernWpf against MahApps, WPF UI and Material Design in XAML

The alternatives people search for alongside ModernWpf differ mainly in where their visual language comes from. MahApps.Metro implements its own Metro-derived control set and window chrome, and its styling is maintained by that project rather than derived from Windows platform resources. ModernWpf's README states that its stock control styling uses official WPF Fluent resources on net10.0-windows7.0 and a compatible backport on older targets, and that its additional controls are ports of microsoft-ui-xaml APIs. That is the real difference: ModernWpf tracks upstream Fluent and WinUI definitions, while MahApps defines its own look. The trade-off is that ModernWpf inherits upstream churn, and its own 1.x line is still a preview.

WPF UI is another Fluent-oriented option, and the comparison search terms suggest users weigh the two directly. The README does not describe WPF UI's internals, so the honest distinction is narrower: ModernWpf documents a per-target split where net10.0-windows7.0 uses the platform Fluent theme and older frameworks use a backport, plus a set of WinUI control ports. Material Design in XAML takes a different direction entirely, implementing Material Design rather than Fluent, so it is a choice about visual language rather than a like-for-like replacement. Adonis UI sits in the same category of general-purpose WPF theming libraries. None of these is interchangeable with ModernWpf at the XAML level, because each ships its own resource keys and control templates.

Editorial conclusion

Adopt ModernWpf if you have an existing WPF codebase on net462, net8.0-windows7.0 or net10.0-windows7.0 and want Fluent styling without moving off WPF. Do not adopt it if you are still pinned to 0.9.x and unwilling to run the migration guide, since source and binary compatibility with that line is not promised, and the MahApps adapter was removed in 1.x. Before committing, verify the exact ModernWpfUI version resolves on NuGet, confirm which of your target frameworks gets the ModernWPF backport rather than the official PresentationFramework.Fluent theme, and check your XAML for APIs the migration guide lists as renamed.

Frequently asked questions

Official sources

1. Issues
2. Kinnara/ModernWpf on GitHub
3. License: MIT
4. README
5. Releases