WPF DataGrid in 2026: Still Here, Still Unmatched

Remember when WPF was supposed to die? UWP was going to replace it. Then WinUI 3 was the future. MAUI came next. After that, Blazor Hybrid. Each time, the message was the same: stop building desktop apps the old way, the new thing is here. And each time, the thousands of companies running complex WPF DataGrid-driven applications — trading floors, manufacturing dashboards, hospital systems, logistics platforms — kept running them. Because they worked. Nothing else offered the same depth for Windows-native desktop UI. And rewriting a 200,000-line LOB app for the framework-of-the-year was never a serious option. Fast forward to 2026. .NET 10 shipped in November 2025 as a Long-Term Support release that Microsoft supports through 2028. It includes WPF. Microsoft added performance optimizations, Fluent UI improvements, and XAML parsing enhancements. WPF didn’t just survive — the team that built it keeps maintaining it. So where does that leave the DataGrid that WPF developers actually rely on every day?

The built-in DataGrid: frozen since 2010

Here’s something that doesn’t get talked about enough. Microsoft added the System.Windows.Controls.DataGrid to WPF in .NET Framework 4.0 — that was April 2010. Before that, it existed as a separate download in the WPF Toolkit for .NET 3.5. In the sixteen years since it became a built-in control, Microsoft has added zero new features to it. Not one. The only changes since then: accessibility fixes in .NET Framework 4.7.1 (screen readers now correctly announce grid cells) and routine code cleanup. That’s it. If you look at the dotnet/wpf repository on GitHub right now, you’ll find open issues for DataGrid memory leaks, choppy scrolling with large datasets, and broken clipboard behavior. Some of these have been open for years. None of this makes the built-in WPF DataGrid a bad control. For a simple table — a few hundred rows, basic sorting, straightforward column binding — it does the job and costs nothing. But it hasn’t evolved because Microsoft’s investment in WPF goes toward the platform, not individual controls. If you need grouping with summaries, master-detail hierarchies, asynchronous data loading, Excel export, or anything beyond displaying flat rows — the built-in grid isn’t going to help you. Microsoft didn’t design it for that in 2010, and nobody has extended it since.

Meanwhile, the ecosystem went chasing frameworks

Something interesting happened over the last decade. When Microsoft started pushing UWP, a lot of component vendors followed. They built UWP control suites, invested engineering time, shipped products. Then UWP’s momentum stalled. WinUI 3 came next. Same cycle — vendors built new suites, reworked their controls for the new platform. Then WinUI 3 struggled with adoption and feature gaps. MAUI followed. Blazor Hybrid after that. Each framework shift meant splitting engineering teams further, maintaining more codebases, and spreading thinner across platforms that kept changing direction underneath them. Through all of it, WPF kept running in production. The apps didn’t care about Microsoft’s framework strategy — they cared about working.

Xceed DataGrid for WPF: 19 years of not getting distracted

Xceed released DataGrid for WPF in 2007 — a year before the built-in DataGrid even existed as a toolkit download. Xceed was the first commercial WPF control vendor, period. The company itself has been around since 1994, and their components ended up inside Microsoft Office 2007, Team Foundation Server, Windows Home Server, and Flight Simulator. That’s 19 years of building DataGrid WPF controls specifically. Not 19 years split across five frameworks. Not 19 years of maintaining a WPF product on the side while the A-team worked on the web version. Nineteen years of treating WPF as the primary platform. While other vendors were staffing up UWP teams, then WinUI 3 teams, then MAUI teams — Xceed kept shipping WPF updates. Over 185 features. 18 built-in themes. And it still runs on the latest version of .NET.

Running on .NET 10: zero friction

We took the Xceed DataGrid demo project, retargeted it to .NET 10, and ran it. Here’s the project file:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>WinExe</OutputType>
    <TargetFramework>net10.0-windows</TargetFramework>
    <Nullable>enable</Nullable>
    <ImplicitUsings>enable</ImplicitUsings>
    <UseWPF>true</UseWPF>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Xceed.Products.Wpf.DataGrid.Full" Version="7.3.25458.6675" />
  </ItemGroup>
</Project>

Build. Run. Everything works — Tableflow scrolling, grouping, master-detail, theming, the whole suite. No compatibility shims, no workarounds, no “partially supported” caveats. A control that Xceed first shipped when .NET 3.0 was current, running without issues on .NET 10. That’s what long-term platform investment looks like. And because .NET 10 is an LTS release (Microsoft supports it through November 2028), this combination will be a stable target for years.

What you still can’t get anywhere else

I’m not going to walk through every feature — there’s a full getting started tutorial and 28 sample applications for that. Instead, here are the things that still have no real equivalent in any other WPF DataGrid, built-in or otherwise.

Async data virtualization

This is the single biggest differentiator and has been for years. Most grids do UI virtualization — only rendering the visible rows. Xceed goes further with asynchronous data virtualization: the grid fetches data from your source in the background, caches pages, and preemptively loads nearby data before the user scrolls to it. Your UI never freezes, even with millions of rows. If your data lives in a database or behind an API — which, in any serious application, it does — this is the feature that matters most. The built-in DataGrid can’t do it. You’d have to build the entire paging and caching infrastructure yourself. There’s a practical walkthrough on rendering 1 million rows without freezing the UI if you want to see the details.

Tableflow view

Xceed’s Tableflow is an animated table view with smooth inertial scrolling (it feels like scrolling on a phone, not a 2008 desktop app), sticky group headers that stay visible as you scroll through grouped data, and column reordering through drag-and-drop with visual feedback.

<xcdg:DataGridControl ItemsSource="{Binding Employees}">
    <xcdg:DataGridControl.View>
        <xcdg:TableflowView AllowColumnChooser="True"
                            IsAlternatingRowStyleEnabled="True" />
    </xcdg:DataGridControl.View>
</xcdg:DataGridControl>

One property to switch views. The AllowColumnChooser adds a UI for users to toggle column visibility. These are small touches, but they’re the difference between a grid that feels like a modern application and one that feels like a spreadsheet from another era.

Master-detail with a single scrollbar

Need to show orders with their line items? Departments with employees? Parent records with child records? Xceed handles this with a DataRelation-based approach where detail rows expand inline, underneath the parent row, sharing a single scrollbar for the entire hierarchy.

<xcdg:DataGridControl x:Name="masterDetailGrid"
                      AutoCreateDetailConfigurations="True"
                      ReadOnly="True">
    <xcdg:DataGridControl.DetailConfigurations>
        <xcdg:DetailConfiguration RelationName="OrderDetails"
                                  Title="Order Details">
            <xcdg:DetailConfiguration.Columns>
                <xcdg:Column FieldName="OrderId" Visible="False" />
                <xcdg:Column FieldName="DetailId" Visible="False" />
            </xcdg:DetailConfiguration.Columns>
        </xcdg:DetailConfiguration>
    </xcdg:DataGridControl.DetailConfigurations>
</xcdg:DataGridControl>

Out of the box, the built-in DataGrid doesn’t support master-detail at all. The usual workaround — nesting grids inside row details templates — gives you multiple scrollbars, broken keyboard navigation, and a debugging experience that nobody enjoys. Xceed’s implementation avoids all of that. There’s documentation on binding to master-detail data tables with more complex hierarchy examples.

18 themes out of the box

The built-in DataGrid ships with one look, and it’s the same look it had in 2010. Xceed ships 18 themes — Windows 10, Material Design, Aero, Metro Light/Dark, Office 2007 variants, and more. Apply one in XAML:

<xcdg:DataGridControl ItemsSource="{Binding Products}">
    <xcdg:DataGridControl.View>
        <xcdg:TableflowView>
            <xcdg:TableflowView.Theme>
                <tp5:Windows10Theme />
            </xcdg:TableflowView.Theme>
        </xcdg:TableflowView>
    </xcdg:DataGridControl.View>
</xcdg:DataGridControl>

You can switch themes at runtime and each theme is a separate assembly — you only load what you use. If you need all standard WPF controls to match, Xceed also has a Pro Themes package that styles everything consistently.

The honest comparison

Feature	Built-in WPF DataGrid	Xceed DataGrid for WPF
First released	2010 (.NET 4.0)	2007
Last feature update	2010	Active (v7.3, 2025)
.NET 10 support	Yes	Yes
UI Virtualization	Basic	Full (including grouped data)
Async Data Virtualization	No	Yes
Smooth Scrolling	No	Yes (inertial)
Master-Detail	No	Yes (single scrollbar)
Multi-Level Grouping	Limited	Full with summaries
Auto-Filtering (Excel-style)	No	Yes
Built-in Themes	1	18
Excel/CSV Export	No	Yes
Printing	No	Yes
3D Views	No	Yes
Rich Editors	Basic	Full suite

When you don’t need any of this

I’d be doing you a disservice if I didn’t say this: not every project needs Xceed. If you’re building a small internal tool, a quick prototype, or anything where the grid shows a few dozen rows with basic sorting — the built-in DataGrid is perfectly fine. It’s free, it’s already in the framework, and it’ll handle simple scenarios without any issues. Xceed makes sense when the requirements are real: large datasets that need async loading, hierarchical data with master-detail, export to Excel for business users, theming that matches a modern UI, or an application that’s going to be maintained for years and needs a grid that keeps up. Pricing is per-developer with no runtime royalties. You can request a free trial to evaluate it. The NuGet package gets you running in minutes.

The long game

WPF outlasted UWP. It outlasted the WinUI 3 hype cycle. It’s shipping in .NET 10 with ongoing improvements, and there’s no sign of that changing. The applications built on it aren’t going anywhere — they’re too embedded, too complex, and too valuable to rewrite for the framework-of-the-year. Xceed DataGrid for WPF has been here for 19 of those years. First commercial WPF control on the market, still actively developed, still running clean on the latest .NET. When you’re choosing a WPF DataGrid for a project that needs to last, the track record matters as much as the feature list.

Ready to try Xceed DataGrid for WPF?

19 years of WPF-focused development. 185+ features. Running on .NET 10 today. Start your free trial Install via NuGet

Frequently asked questions

Is WPF still supported in .NET 10?

Yes — and it’s not just “supported” in the sense of bug fixes. Microsoft shipped real improvements in .NET 10: the team replaced internal data structures with faster base types, optimized font rendering, and made XAML parsing faster. Meanwhile, the dotnet/wpf repository accepts community PRs and sees regular commits. .NET 10 is an LTS release, meaning Microsoft will support WPF on this version through at least November 2028.

Has the built-in WPF DataGrid been updated recently?

It last received a new feature in 2010. Since then: one round of accessibility fixes in .NET 4.7.1, and routine code cleanup. If you check the dotnet/wpf GitHub issues, you’ll find long-standing DataGrid bugs around memory leaks and scroll performance that are still open. Microsoft maintains WPF the platform — but the DataGrid control itself is effectively done.

Does Xceed DataGrid for WPF work on .NET 10?

Yes. We retargeted an existing project to net10.0-windows and ran it with no code changes. The grid, Tableflow animations, master-detail expansion, theme switching, and data virtualization all behaved identically to .NET 8. The NuGet package installs and resolves cleanly on .NET 10.

What’s the best WPF DataGrid for large datasets?

With large data, the bottleneck isn’t rendering — it’s loading. Most grids (including the built-in one) only virtualize the UI: they still expect all your data in memory. Xceed is different because it virtualizes the data layer too — fetching pages asynchronously, caching them, and pre-loading what the user is likely to scroll to next. That’s why it handles millions of rows without the UI ever locking up.

How old is Xceed DataGrid for WPF?

Nineteen years. It shipped in 2007, three years before Microsoft added a DataGrid to WPF itself. Xceed the company goes back to 1994 — their zip and compression libraries were some of the first commercial .NET components. Their code has shipped inside Microsoft Office, Team Foundation Server, and Flight Simulator.