# Fluent.Ribbon: an open source Office-style ribbon for WPF, still on a .NET 10 SDK > A C# library that reimplements the Office ribbon for Windows Presentation Foundation, now at version 11 and tracking current Office theming, with an unusually disciplined breaking-change policy. **fluentribbon/Fluent.Ribbon** — WPF Ribbon control like in Office - Repository: https://github.com/fluentribbon/Fluent.Ribbon - Website: http://fluentribbon.github.io - Stars: 2,761 · Forks: 542 - Language: C# - License: MIT - Published: 2026-10-06 · Updated: 2026-10-06 · Language: en - Canonical page: https://hysenlabs.com/projects/fluentribbon-fluent-ribbon ## The ribbon Microsoft never gave you as a library The project's own description is four words long: WPF Ribbon control like in Office. That brevity is accurate, and it points at the gap this library fills. Office has shipped a ribbon since 2007 and Windows has shipped the UX guidelines for it, but WPF itself never included a supported ribbon control. Teams that wanted one either hand-rolled it or reached for a third-party library, and Fluent.Ribbon is the one that became the default answer. The library is a set of controls rather than a framework, which is the right shape for this problem. It provides RibbonTabControl, Backstage, Gallery, QuickAccessToolbar, ScreenTip and more, in the vocabulary Office actually uses. You assemble a ribbon in XAML and bind commands to it, and the library handles the layout, grouping, and the visual behaviour users already know how to operate. That prior knowledge is the real argument. Nobody needs training for a ribbon because they have used one for nearly two decades. The repository points at the Microsoft command ribbons article on MSDN for the concept itself, which is a deliberate choice to treat the ribbon as a solved design problem rather than something to reinvent. WPF is the hard constraint worth stating plainly. This is a Windows Presentation Foundation library written in C#, so it is Windows only. If your application targets cross-platform .NET, this is not an option. ## Version 11 broke the API on purpose, in documented detail Version 11.0.0, released on 2025-03-02, is the release that tells you how this project is run, because it is long and specific about what changed and why. The framework change came first: support for .NET 5.0 and .NET 3.1 was dropped, and .NET 6.0 and .NET 8.0 were added. The headline feature is described as aligning theming with current office versions, which in practice means visual differences from the previous theming. Then the breaking changes are enumerated control by control. Backstage lost its default MinWidth on the button that opens it, and saving and restoring window sizes was removed. BackstageTabControl had IsWindowStewingHelperEnabled and SelectedContentMargin removed. BackstageTabItem changed when selection happens, moving from mouse button up to mouse button down, and from Space or Enter key press to focus retrieval. RibbonContextualTabGroup now always takes the width of its containing tabs. RibbonGroupBox changed its default Padding and lost a ClearCache method. RibbonTabItem changed default HeaderPadding and Padding values, replaced IsSeparatorVisible with SeparatorOpacity, and now forwards Padding to the content Margin. What stands out is the granularity. Someone chose to document each default padding change rather than write a summary line. For a library with this many downstream consumers, that is exactly the documentation an upgrading maintainer needs, and it is the single strongest quality signal in the repository. ## Two patch releases that read like a bug tracker summary Version 11.0.1 from 2025-05-24 and 11.0.2 from 2026-01-19 are small, and their changelogs are effectively bug lists. The 11.0.1 release fixed MenuItems that use ItemSource alongside a nested MenuItem, a window that could not be dragged with the mouse under .NET 10, a crash inside StyleHelper.EvaluateOldNewStates, a wrong margin in TwoLineLabel, a minor display issue caused by TextFormattingMode.Ideal, and an ItemsControl in a ContextMenu creating a hierarchical layer it should not have. It also credits a contributor for supplying the test code on the MenuItem fix, which is the sort of detail that tells you the test suite is community-extended. The 11.0.2 release fixed a single issue: an empty ContextMenu appearing when ribbon controls were used outside of a Ribbon. That is a narrow bug, but it is exactly the kind of edge case that only shows up once a control library is used in ways its authors did not anticipate. Two observations follow. First, the mouse-drag fix under .NET 10 is a reminder that WPF is a framework with sharp edges, and a library built on it inherits them. Second, the gap between 2025-05-24 and 2026-01-19 for a one-line fix is what a small maintenance team looks like. The repository is not archived and the last push was on 2026-09-13, so it is still moving, but the release cadence is that of a mature library with a handful of regular contributors. ## The showcase application is the documentation Instead of a tutorial, this project ships a demonstration application and tells you to read that. The README states that almost all features are shown in the demo application, and that if something appears to be missing you should open an issue. The practical consequence is good news for anyone evaluating it. That demo app is included with every release, so you can download a stable version from the releases page or a preview from CI artifacts, run it, and see RibbonTabControl, Backstage, galleries, and quick access toolbars behaving. That is faster than evaluating documentation, and it is how you would check whether the current Office theming looks right in your own visual context. For preview builds there is a dedicated AppVeyor NuGet feed, which is worth knowing about because it means you can evaluate unreleased changes without waiting for a tag. The default branch is develop, and the CI configuration builds both master and develop, with a separate badge for the test run on develop. Two supporting conventions reinforce the same approach. Changelog.md maintains the history of changes, and GitHub milestones hold the roadmap, so pending work is visible rather than promised. The documentation itself lives at fluentribbon.github.io/documentation, separate from the repository. ## Building it needs .NET 10, Nuke, and a specific XAML style The development requirements are short: .NET SDK 10.0.100 or later, and an IDE that supports that SDK. Everything else is a convention. The repository root reveals the build system. There is a Build.ps1 alongside build.cmd and build.sh, plus a .nuke directory, which is the Nuke build system. That means the build is a C# project, not a shell script, so you can step through it in a debugger if something goes wrong. Rounding it out are Directory.build.props, Directory.build.targets, Directory.packages.props for central package version management, GitVersion.yml for deriving the version from git history, and appveyor.yml as the CI definition. The formatting rules are just as specific, which tells you this is a project with many contributors and an opinion about consistency. General formatting follows an .editorconfig, and there is a separate Settings.XAMLStyler file with an explicit XAML rule: position each attribute on a separate line, but put the first attribute on the same line as the start tag. There is also a Fluent.Ribbon.ruleset for code analysis and a Fluent.Ribbon.sln.DotSettings shared with ReSharper. The README even documents a designer workaround, which is a good sign about how much time people spend in the designer. If the Visual Studio designer misbehaves, clear the Designer ShadowCache under %LOCALAPPDATA% for your version, or delete the .vs folder in your development folder. ## An MIT library that came from CodePlex and wants help The project was previously hosted on CodePlex, which dates it more precisely than a copyright line would. CodePlex was Microsoft hosted for projects that had nowhere else obvious to go, and Fluent.Ribbon was one of the notable WPF libraries to graduate from it. The MIT licence means you can use it commercially, modify it, and vendor it, with no copyleft obligation beyond keeping the notice. The README closes with a help wanted list that is worth reading as a health signal: pull requests are accepted, and the project asks for help fixing bugs, translating, and updating documentation. That list is short and specific, which is more useful than a generic invitation to contribute. The topics include hacktoberfest and a showcase-application tag, confirming both of those paths are real. The homepage is fluentribbon.github.io, the CI runs on AppVeyor, and the package is on NuGet as Fluent.Ribbon. Fifteen open issues against a library with thousands of stars is a low number, and with a release every few months and a changelog maintained in the repository, the project reads as quietly kept rather than actively expanded. So the honest summary is this. Fluent.Ribbon solved a specific and durable problem for WPF, and the maintainers have spent a decade keeping it working against new .NET versions and new Office theming rather than adding new ideas. That is a good deal for anyone who needs a ribbon, and a poor one for anyone who needs a modern cross-platform UI toolkit. ## Conclusion Fluent.Ribbon exists because Microsoft never shipped a ribbon control as a supported library, and this is the community answer that stuck. What it gives you is concrete: RibbonTabControl, Backstage, Gallery, QuickAccessToolbar, ScreenTip, and a theme aligned with current Office versions, under the MIT licence. The cost is that it is a WPF library on a .NET 10 SDK, so it is a Windows-only choice, and version 11 broke enough of the surface that upgrading from 10 means reading Changelog.md carefully. The default branch is develop, not main, and preview builds come from an AppVeyor NuGet feed rather than nuget.org. Start by running the bundled demo application from a release download, because it demonstrates almost every feature and is faster than reading the documentation site. ## FAQ ### What controls does Fluent.Ribbon provide? The README names RibbonTabControl, Backstage, Gallery, QuickAccessToolbar, and ScreenTip among the controls. Backstage is the full-window view behind the ribbon tab, Gallery gives the Office-style dropdown grid of items, and QuickAccessToolbar is the small row of buttons above the tabs. ### Is Fluent.Ribbon still maintained? The repository is not archived and the last push was on 2026-09-13. Version 11.0.0 landed on 2025-03-02 with a detailed list of breaking changes, followed by 11.0.1 in May 2025 and 11.0.2 in January 2026. The cadence is that of a mature library kept working rather than one gaining new capabilities. ### Does Fluent.Ribbon work with .NET 10? Yes. Building the library requires .NET SDK 10.0.100 or later, and version 11.0.1 includes a fix for a window that could not be dragged with the mouse under .NET 10. Version 11.0.0 dropped .NET 5.0 and .NET 3.1 and added .NET 6.0 and .NET 8.0. ### What are the breaking changes in Fluent.Ribbon 11? Several. Backstage lost its default MinWidth and its window size saving, BackstageTabControl removed IsWindowStewingHelperEnabled and SelectedContentMargin, BackstageTabItem selects on mouse down and on focus rather than mouse up or Space, RibbonGroupBox lost ClearCache, and RibbonTabItem replaced IsSeparatorVisible with SeparatorOpacity. Changelog.md in the repository lists all of them per control. ## Sources - [fluentribbon/Fluent.Ribbon on GitHub](https://github.com/fluentribbon/Fluent.Ribbon) - [License: MIT](https://github.com/fluentribbon/Fluent.Ribbon/blob/develop/LICENSE) - [Project website](http://fluentribbon.github.io) - [README](https://github.com/fluentribbon/Fluent.Ribbon/blob/develop/README.md) - [Releases](https://github.com/fluentribbon/Fluent.Ribbon/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/fluentribbon-fluent-ribbon