DEV Community: s-iguchi09

Binding to the Parent DataContext from Inside a WPF DataTemplate

s-iguchi09 — Sat, 26 Sep 2026 08:21:22 +0000

Originally published at s-iguchi09.github.io.
A Japanese version is also available.

Overview

A button placed inside the DataTemplate of an ItemsControl or ListBox often fails to invoke a command that lives on the parent view model.
The binding expression itself is correct: it is evaluated exactly as written, but the DataContext it starts from has been switched to the individual item, so the target member is never reached.
This article explains the cause in terms of DataContext inheritance and compares four ways to reach the parent — RelativeSource, ElementName, x:Reference, and PlacementTarget — based on measured behavior inside a DataTemplate and inside a ContextMenu or ToolTip.

Prerequisites / Environment

Framework: .NET 6 or later / WPF
Language: C# 9 or later / XAML (the code samples assume target-typed new and enabled nullable reference types; on C# 8 and earlier, state the type explicitly and drop !)
Target features: ItemTemplate / DataTemplate of ItemsControl-derived controls, plus ContextMenu and ToolTip
Architecture: MVVM, where commands and shared display values belong to the parent view model rather than to each item
Behavior verified on: .NET 10 / Windows 11

Problem

Consider a list where each row carries a delete button, with the command bound inside the DataTemplate.

<ItemsControl ItemsSource="{Binding Items}">
    <ItemsControl.ItemTemplate>
        <DataTemplate>
            <StackPanel Orientation="Horizontal">
                <TextBlock Text="{Binding Name}" />
                <Button Content="Delete" Command="{Binding DeleteCommand}" />
            </StackPanel>
        </DataTemplate>
    </ItemsControl.ItemTemplate>
</ItemsControl>

DeleteCommand belongs to the parent view model assigned to the DataContext of the ItemsControl, not to the elements of Items.
Clicking the button does nothing.
The button is not rendered as disabled either, so it remains fully clickable and the failure is invisible on screen.

The Output window records the following binding error, emitted as a single line and wrapped here for readability.

System.Windows.Data Error: 40 : BindingExpression path error: 'DeleteCommand' property not found on
'object' ''Measurement' (HashCode=58682725)'. BindingExpression:Path=DeleteCommand;
DataItem='Measurement' (HashCode=58682725); target element is 'Button' (Name='');
target property is 'Command' (type 'ICommand')

The decisive detail is that DataItem names the item type (Measurement here) rather than the parent view model.
Reading these messages in general is covered in Reading WPF Binding Errors and Diagnosing Them with the Output Window.

Cause / Background

When a Binding specifies none of Source, RelativeSource, or ElementName, it resolves Path against the DataContext of the target element.
DataContext is inherited down the element tree, so a view model assigned to the Window normally reaches every descendant.

ItemsControl interrupts that inheritance.
It generates a container for each element of ItemsSource, such as a ContentPresenter or a ListBoxItem, and assigns the corresponding data item to that container's DataContext.
Because the container's own DataContext is the item, a binding written in an ItemContainerStyle setter resolves against the item as well (see Selecting and Expanding a WPF TreeView Node from Code, and Why SelectedItem Is Read-Only).
Because DataContext is an inherited property, elements expanded from the DataTemplate receive the container's value unchanged.
As a result, {Binding DeleteCommand} inside the template looks for DeleteCommand on the item, does not find it, and leaves the binding unresolved.

The easily missed consequence is that a failed Command binding does not disable the button.
Through Command, a button renders as disabled when the ICommand assigned to it returns false from CanExecute.
With Command left at null there is nothing to evaluate, and IsEnabled stays true.
This applies to any control implementing ICommandSource, MenuItem included, not only to Button.
The visible state therefore looks correct, and the only symptom is that clicking has no effect.
A command that is assigned correctly but never toggles between enabled and disabled has a different cause, covered in Fixing a RelayCommand Whose CanExecute Does Not Update the Button State in WPF.

A plain {Binding} only walks the DataContext, so it has no way to cross this switch.
Crossing it requires either walking up the element tree or referring to the target element by name.

The following diagram shows where the DataContext switches and where the element tree itself is severed.

Figure: Diagram showing the DataContext switching to the item from ContentPresenter downward in the window element tree, and the ContextMenu inside a Popup detached from that tree, where RelativeSource and ElementName stop at the boundary while PlacementTarget still points at the owning element.

The DataContext switch (blue is the parent view model, red is the item) and the element tree severed by the Popup. On the left, the walk up to the ItemsControl succeeds; inside the Popup on the right no such path exists, and only PlacementTarget reaches the owning element.

The diagram is rendered in the original article.

The figure below records whether the Command inside the template resolves, per way of writing the binding.

Figure: A table of whether Button.Command inside a DataTemplate resolves, per binding style. A plain Binding leaves Command null; RelativeSource and ElementName both resolve it. IsEnabled stays True in every case.

Measured on .NET 10 / Windows 11 by reading Command off the Button placed in an ItemsControl.ItemTemplate. Nothing differs between the rows except how the binding is written.

The diagram is rendered in the original article.

Note the IsEnabled column. It stays True even on the row where Command is null.
A failed resolution changes nothing visible, so it cannot be spotted by looking at the screen.
All that remains is the symptom: clicking does nothing.

Solution

Use the FindAncestor mode of RelativeSource to walk up to an ancestor that still holds the original DataContext, then reach the member through that DataContext.

Prefer ItemsControl as the ancestor type.
Window or UserControl also works, but moving the template into another view or UserControl changes the surrounding structure, so ItemsControl survives reuse better.

Prefix the path with DataContext..
RelativeSource returns the ancestor element, and its DataContext is not traversed automatically.
Conversely, omit DataContext. when the target is a dependency property of the ancestor element itself.
Referencing a dependency property defined on a UserControl from inside that control is one such case (see Binding to a WPF UserControl's Own Dependency Property from Inside the Control).

Implementation

The following XAML places a plain binding and a RelativeSource binding side by side inside the same DataTemplate.
Both attempt to display Unit, which only the parent view model owns, so the sole difference is how the parent is reached.

<ItemsControl ItemsSource="{Binding Items}">
    <ItemsControl.ItemTemplate>
        <DataTemplate>
            <StackPanel Orientation="Horizontal">
                <TextBlock Text="{Binding Name}" />
                <TextBlock Text="{Binding Value}" />

                <!-- The item has no Unit, so this stays empty -->
                <TextBlock Text="{Binding Unit}" />

                <!-- Walks up to the ItemsControl and reads Unit from its DataContext -->
                <TextBlock Text="{Binding DataContext.Unit,
                                  RelativeSource={RelativeSource AncestorType={x:Type ItemsControl}}}" />

                <Button Content="Delete"
                        Command="{Binding DataContext.DeleteCommand,
                                  RelativeSource={RelativeSource AncestorType={x:Type ItemsControl}}}"
                        CommandParameter="{Binding}" />
            </StackPanel>
        </DataTemplate>
    </ItemsControl.ItemTemplate>
</ItemsControl>

CommandParameter="{Binding}" deliberately uses a plain binding and passes the DataContext of that element, which is the item itself.
The division is that the parent view model supplies which member to invoke, while the item supplies what to invoke it on.

The matching view model is shown below.
Unit and DeleteCommand are declared here rather than on the item type.

public sealed class Measurement
{
    public Measurement(string name, int value)
    {
        Name = name;
        Value = value;
    }

    public string Name { get; }

    public int Value { get; }
}

public sealed class MeasurementListViewModel
{
    public MeasurementListViewModel()
    {
        DeleteCommand = new RelayCommand(item => Items.Remove((Measurement)item!));
    }

    public string Unit => "kg";

    public ObservableCollection<Measurement> Items { get; } = new()
    {
        new Measurement("A", 120),
        new Measurement("B", 80),
        new Measurement("C", 240),
    };

    public ICommand DeleteCommand { get; }
}

Measurement is deliberately not a record, because ObservableCollection<T>.Remove deletes the first element that compares equal.
Records compare by value, so with two identical rows the deletion removes the first one rather than the row that was clicked.

RelayCommand stands in for any ICommand implementation with a constructor that takes an Action<object?>; an implementation with a fixed parameter type, such as RelayCommand<Measurement> in CommunityToolkit.Mvvm, is the equivalent.
Assigning this instance to the DataContext of the Window lets the ItemsControl inherit it, which is where the RelativeSource bindings land.

Displaying the XAML above, with an added header identifying each expression and a frame around each value, makes the difference between the two bindings visible.

Result of the two bindings placed in the same DataTemplate. The left box uses {Binding Unit} and resolves against the item, leaving it empty; the right box walks up to the ItemsControl and shows the value from the parent view model. The header text and the frames around each value were added to the figure to identify which expression produced each result and to make the empty box visible. The delete button is omitted from the figure because it plays no part in the contrast between the two bindings (produced on .NET 10 / Windows 11).

Notes

ElementName also resolves from inside a DataTemplate. A DataTemplate establishes its own XAML namescope, but WPF resolves ElementName by searching outward into enclosing namescopes, so {Binding DataContext.DeleteCommand, ElementName=RootWindow} works inside a template (verified on .NET 10 / Windows 11). The common claim that ElementName cannot be used inside templates does not apply to WPF. The namescope restriction on markup-based ElementName resolution is documented for the WinUI Binding.ElementName; the WPF documentation carries no equivalent restriction. It does depend on the referenced name, so the binding breaks once the template moves to another view.
Neither RelativeSource nor ElementName reaches out of a ContextMenu or ToolTip. Both are hosted inside a Popup, and a Popup renders its content in a separate window on screen. Elements inside the popup are therefore detached from the element tree of the application window, and since both ancestor lookup and name resolution walk that tree, neither crosses the boundary. Unlike the DataTemplate case, no outward path exists at all. The Output window records Cannot find source for binding with reference 'RelativeSource FindAncestor, AncestorType='System.Windows.Window', AncestorLevel='1'' or Cannot find source for binding with reference 'ElementName=RootWindow'.
A ContextMenu inherits its DataContext from the element that owns it. When the ContextMenu is attached to an element inside a DataTemplate, the inherited value is that element's DataContext, which is the item. A plain {Binding} inside the menu therefore resolves against the item exactly as it does inside the template, and still never reaches the parent view model.
ContextMenu derives from ItemsControl. Specifying AncestorType={x:Type ItemsControl} inside a ContextMenu matches the ContextMenu itself rather than the outer list. Ancestor type lookup therefore does not behave as intended inside a ContextMenu.
Both the inherited DataContext and PlacementTarget are established as the menu opens. For a ContextMenu assigned to FrameworkElement.ContextMenu, ContextMenuService sets PlacementTarget to the owning element as the menu opens. Before that, PlacementTarget and DataContext are both null, and neither is set yet at the ContextMenuOpening stage. A binding that goes through PlacementTarget therefore does not resolve until the menu opens. Because PlacementTarget is a dependency property, the binding is re-evaluated once it is assigned and resolves correctly from then on.
x:Reference carries a documented restriction. x:Reference is XAML 2009 syntax, and the documentation states that XAML 2009 features are usable in WPF only for XAML that is not markup-compiled. In practice {x:Reference} written in a .xaml page resolves both inside a DataTemplate and inside a ContextMenu (verified on .NET 10 / Windows 11), but it falls outside what the documentation guarantees, so it should not be the first choice. The same documentation also states that ElementName binding should still be used for most WPF applications.

Alternatives / Comparison

The table lists whether each mechanism reaches the parent view model, measured inside a DataTemplate and inside a ContextMenu or ToolTip.

Approach	Inside DataTemplate	Inside ContextMenu / ToolTip	Pros	Cons
Plain `{Binding X}`	Not reachable	Not reachable	Shortest to write	`DataContext` switches to the item, so the parent is out of range
`RelativeSource` `AncestorType`	Reachable	Not reachable	No name dependency, survives template reuse	Depends on tree structure. Cannot cross the popup boundary
`ElementName`	Reachable	Not reachable	Short, and no ancestor type to choose	Depends on the referenced name. Cannot cross the popup boundary
`x:Reference`	Reachable	Reachable	Crosses the popup boundary	XAML 2009 feature with a documented restriction
`PlacementTarget` + `Tag`	Not applicable	Reachable	Works reliably in popups	Occupies `Tag`. `PlacementTarget` is `null` until the menu opens

The table narrows the options by reachability; which one to pick under which condition follows the selection criteria in the summary.

To reach the parent view model from a ContextMenu, stash the parent DataContext in the owner's Tag and read it back through PlacementTarget.

<Border Tag="{Binding DataContext,
              RelativeSource={RelativeSource AncestorType={x:Type ItemsControl}}}">
    <Border.ContextMenu>
        <ContextMenu>
            <MenuItem Header="Delete"
                      Command="{Binding PlacementTarget.Tag.DeleteCommand,
                                RelativeSource={RelativeSource AncestorType={x:Type ContextMenu}}}"
                      CommandParameter="{Binding}" />
        </ContextMenu>
    </Border.ContextMenu>
</Border>

The Border that sets Tag sits inside the DataTemplate, so RelativeSource can still reach the ItemsControl from there.
The MenuItem walks up to the ContextMenu, then reads the Tag of its PlacementTarget, which is that Border, and arrives at the parent view model.
CommandParameter="{Binding}" resolves against the item the ContextMenu inherited from its owner, so the target item still travels with the command.

The same structure applies to a ToolTip, with the ancestor type changed accordingly.

<TextBlock Text="{Binding PlacementTarget.Tag.Unit,
                  RelativeSource={RelativeSource AncestorType={x:Type ToolTip}}}" />

To cross the popup boundary without occupying Tag, use x:Reference.
It supplies the element itself as Source, so neither the element tree nor a name resolution path is walked.

<TextBlock Text="{Binding Source={x:Reference RootWindow}, Path=DataContext.Unit}" />

Summary

A binding that cannot reach the parent view model from inside a DataTemplate is not a syntax problem: the starting DataContext has been switched to the item.
For a Command, the button stays enabled and silently does nothing, so the diagnosis comes from the DataItem value in the Output window rather than from the visible state.

Choose as follows.

Ordinary DataTemplate content: Use RelativeSource={RelativeSource AncestorType={x:Type ItemsControl}}. It avoids name dependencies and survives reuse of the template in another list.
A template that never leaves its current view: ElementName reaches the parent as well. It removes the need to pick an ancestor type, at the cost of tracking the referenced name.
Inside a ContextMenu or ToolTip: Stash the parent DataContext in the owner's Tag and read PlacementTarget.Tag. RelativeSource and ElementName cannot cross the popup boundary and are not options here.
When Tag is already in use: x:Reference crosses the popup boundary as well. It is a XAML 2009 feature and falls outside what the documentation guarantees, so prefer PlacementTarget wherever it is available.

The most stable structure is to give each item its own view model that owns the operations performed on it.
When the markup accumulates bindings that reach up to parent commands, the first thing to evaluate is whether those commands belong on the item view model instead.

Expressing SQL Outer Joins in LINQ — Implementing LeftJoin, RightJoin and Shuffle

s-iguchi09 — Thu, 17 Sep 2026 14:02:53 +0000

Originally published at s-iguchi09.github.io.
A Japanese version is also available.

Overview

An outer join that SQL writes with a single LEFT JOIN clause required composing three methods in LINQ — GroupJoin, SelectMany and DefaultIfEmpty — for over a decade.
.NET 10 finally closes that gap by adding LeftJoin and RightJoin as first-class operators.
Alongside them, random reordering — long imitated with the OrderBy(_ => Guid.NewGuid()) pseudo-idiom — was standardized as Shuffle.

Starting from the correspondence between SQL join clauses and LINQ idioms, this article implements polyfills that make the three operators available on .NET Framework.
It then digs into a concern unique to this backport, born from the fact that outer joins live next door to database queries: applying the polyfill to IQueryable<T> silently breaks query translation.

Prerequisites / Environment

Frameworks: .NET Framework 4.8 (backport target) / .NET 10+ (future migration target)
APIs: LINQ LeftJoin (2 signatures), RightJoin (2 signatures), Shuffle (1 signature)
Approach: apply #nullable enable; disable automatically on migration via #if !NET10_0_OR_GREATER
Language version: nullable annotations on unconstrained type parameters (TInner? / TOuter?) require LangVersion 9.0 or later (recommended: latest). No other project configuration changes

How SQL Join Clauses Map to LINQ Idioms

The three operators added in .NET 10 are the following.

Method	Added in	Corresponding operation
`LeftJoin<TOuter, TInner, TKey, TResult>`	.NET 10.0	SQL `LEFT OUTER JOIN` (keeps every outer element)
`RightJoin<TOuter, TInner, TKey, TResult>`	.NET 10.0	SQL `RIGHT OUTER JOIN` (keeps every inner element)
`Shuffle<TSource>`	.NET 10.0	Random reordering

LINQ before .NET 10 has no dedicated outer-join operator — only Join (inner join).
An operation that SQL expresses in one clause mapped to this:

-- SQL: keep employees with no matching department
SELECT e.Name, d.DeptName
FROM Employee e
LEFT JOIN Department d ON e.DeptId = d.DeptId

// LINQ (.NET 9 and earlier): composing GroupJoin + SelectMany + DefaultIfEmpty
var result = employees
    .GroupJoin(departments, e => e.DeptId, d => d.DeptId, (e, ds) => new { e, ds })
    .SelectMany(g => g.ds.DefaultIfEmpty(), (g, d) => new { g.e.Name, d?.DeptName });

The composed idiom buries the intent — "outer join" — in structure, and misplacing SelectMany or DefaultIfEmpty quietly turns it into an inner or cross join.
Random ordering has the same shape of problem: OrderBy(_ => Guid.NewGuid()) generates a key per element, pays for a full sort, and offers no uniformity guarantee as a shuffle.

Evaluation results when the two sequences contain non-matching keys. LeftJoin keeps the left side and fills the counterpart with null; RightJoin does the reverse. Shuffle randomizes the order, so that row shows the result of a single run.

Implementation

The following is the complete polyfill for LeftJoin (2 signatures), RightJoin (2 signatures) and Shuffle (1 signature).
LeftJoin / RightJoin embed the composition idiom above in the same shape as the built-ins, and Shuffle buffers the source into an array before applying a Fisher–Yates shuffle.
The reasons for placing the polyfill in System.Linq and for the migration guard are covered in the series foundation article.
Add it to the project as, for example, LinqExtensions.Net10.cs.

#nullable enable

using System;
using System.Collections.Generic;

#if !NET10_0_OR_GREATER // Active only below .NET 10.0 (e.g. .NET Framework)

namespace System.Linq
{
    /// <summary>
    /// Provides extension methods that backfill LINQ methods introduced in .NET 10.0 for older target frameworks.
    /// </summary>
    public static partial class LinqExtensions
    {
        // ==========================================
        // 1. LeftJoin (left outer join)
        // ==========================================
        public static IEnumerable<TResult> LeftJoin<TOuter, TInner, TKey, TResult>(
            this IEnumerable<TOuter> outer,
            IEnumerable<TInner> inner,
            Func<TOuter, TKey> outerKeySelector,
            Func<TInner, TKey> innerKeySelector,
            Func<TOuter, TInner?, TResult> resultSelector)
            => outer.LeftJoin(inner, outerKeySelector, innerKeySelector, resultSelector, comparer: null);

        public static IEnumerable<TResult> LeftJoin<TOuter, TInner, TKey, TResult>(
            this IEnumerable<TOuter> outer,
            IEnumerable<TInner> inner,
            Func<TOuter, TKey> outerKeySelector,
            Func<TInner, TKey> innerKeySelector,
            Func<TOuter, TInner?, TResult> resultSelector,
            IEqualityComparer<TKey>? comparer)
        {
            if (outer == null) throw new ArgumentNullException(nameof(outer));
            if (inner == null) throw new ArgumentNullException(nameof(inner));
            if (outerKeySelector == null) throw new ArgumentNullException(nameof(outerKeySelector));
            if (innerKeySelector == null) throw new ArgumentNullException(nameof(innerKeySelector));
            if (resultSelector == null) throw new ArgumentNullException(nameof(resultSelector));

            // Group matching inner elements per outer element; supply default(TInner) when none match.
            return outer
                .GroupJoin(inner, outerKeySelector, innerKeySelector, (o, inners) => new { o, inners }, comparer)
                .SelectMany(g => g.inners.DefaultIfEmpty(), (g, i) => resultSelector(g.o, i));
        }

        // ==========================================
        // 2. RightJoin (right outer join)
        // ==========================================
        public static IEnumerable<TResult> RightJoin<TOuter, TInner, TKey, TResult>(
            this IEnumerable<TOuter> outer,
            IEnumerable<TInner> inner,
            Func<TOuter, TKey> outerKeySelector,
            Func<TInner, TKey> innerKeySelector,
            Func<TOuter?, TInner, TResult> resultSelector)
            => outer.RightJoin(inner, outerKeySelector, innerKeySelector, resultSelector, comparer: null);

        public static IEnumerable<TResult> RightJoin<TOuter, TInner, TKey, TResult>(
            this IEnumerable<TOuter> outer,
            IEnumerable<TInner> inner,
            Func<TOuter, TKey> outerKeySelector,
            Func<TInner, TKey> innerKeySelector,
            Func<TOuter?, TInner, TResult> resultSelector,
            IEqualityComparer<TKey>? comparer)
        {
            if (outer == null) throw new ArgumentNullException(nameof(outer));
            if (inner == null) throw new ArgumentNullException(nameof(inner));
            if (outerKeySelector == null) throw new ArgumentNullException(nameof(outerKeySelector));
            if (innerKeySelector == null) throw new ArgumentNullException(nameof(innerKeySelector));
            if (resultSelector == null) throw new ArgumentNullException(nameof(resultSelector));

            // GroupJoin pivoted on the inner sequence; supply default(TOuter) when none match.
            return inner
                .GroupJoin(outer, innerKeySelector, outerKeySelector, (i, outers) => new { i, outers }, comparer)
                .SelectMany(g => g.outers.DefaultIfEmpty(), (g, o) => resultSelector(o, g.i));
        }

        // ==========================================
        // 3. Shuffle (random reordering)
        // ==========================================
        public static IEnumerable<TSource> Shuffle<TSource>(this IEnumerable<TSource> source)
        {
            if (source == null) throw new ArgumentNullException(nameof(source));
            return ShuffleIterator(source);
        }

        private static IEnumerable<TSource> ShuffleIterator<TSource>(IEnumerable<TSource> source)
        {
            var buffer = source.ToArray();

            // Fisher–Yates: swap each position from the tail with an undecided element.
            for (int i = buffer.Length - 1; i > 0; i--)
            {
                int j = SharedRandom.Next(i + 1);
                if (j != i)
                {
                    (buffer[i], buffer[j]) = (buffer[j], buffer[i]);
                }
            }

            foreach (var item in buffer)
            {
                yield return item;
            }
        }

#if NET6_0_OR_GREATER
        // .NET 6+ provides a thread-safe shared instance.
        private static Random SharedRandom => Random.Shared;
#else
        // .NET Framework has no Random.Shared, so keep one instance per thread.
        [ThreadStatic]
        private static Random? _threadRandom;
        private static Random SharedRandom => _threadRandom ??= new Random();
#endif
    }
}

#endif

Whether this implementation returns what the standard LINQ returns can be checked by building the same calling code for net48 (polyfill active) and for net10.0 (built-in active), running both, and comparing the output.

Figure: A table comparing the output of the same calling code run against the net48 polyfill and the net10.0 built-in. LeftJoin, RightJoin, and Shuffle all produce identical results, boundary cases included.

The implementation above, built as-is for net48 and built for net10.0 where #if switches it to the built-in, run through one and the same driver. Measured with .NET SDK 10.0.302.

The diagram is rendered in the original article.

Shuffle draws on randomness, so its output is re-sorted before the comparison. The two sides also agree on the default value handed to a row that has no counterpart.

The result selectors of LeftJoin / RightJoin carry the same nullable annotations as the built-ins — TInner? for LeftJoin, TOuter? for RightJoin.
The signature itself thus documents which side can be missing, and nullable analysis agrees before and after migration.
Shuffle's random source branches further on a nested #if NET6_0_OR_GREATER: where Random.Shared is unavailable, a [ThreadStatic] instance provides thread safety.

Using `LeftJoin` / `RightJoin`

`LeftJoin`: Keep Every Outer (Left) Element

For outer elements with no matching inner element, the result selector receives default(TInner) (null for reference types) as its second argument.

var employees = new[]
{
    new { Name = "Sato",      DeptId = 10 },
    new { Name = "Suzuki",    DeptId = 20 },
    new { Name = "Takahashi", DeptId = 99 }, // No matching department
};

var departments = new[]
{
    new { DeptId = 10, DeptName = "Sales" },
    new { DeptId = 20, DeptName = "Engineering" },
};

var result = employees.LeftJoin(
    departments,
    e => e.DeptId,
    d => d.DeptId,
    (e, d) => $"{e.Name}: {d?.DeptName ?? "(unassigned)"}");
// Sato: Sales
// Suzuki: Engineering
// Takahashi: (unassigned)

Matching SQL's LEFT JOIN ... ON e.DeptId = d.DeptId, the unmatched "Takahashi" stays in the output.
The second selector argument d is nullable and must be null-checked before use.

`RightJoin`: Keep Every Inner (Right) Element

For inner elements with no matching outer element, the result selector receives default(TOuter) as its first argument.

var employees = new[]
{
    new { Name = "Sato",   DeptId = 10 },
    new { Name = "Suzuki", DeptId = 20 },
};

var departments = new[]
{
    new { DeptId = 10, DeptName = "Sales" },
    new { DeptId = 20, DeptName = "Engineering" },
    new { DeptId = 30, DeptName = "General Affairs" }, // No employees assigned
};

var result = employees.RightJoin(
    departments,
    e => e.DeptId,
    d => d.DeptId,
    (e, d) => $"{d.DeptName}: {e?.Name ?? "(vacant)"}");
// Sales: Sato
// Engineering: Suzuki
// General Affairs: (vacant)

RightJoin(outer, inner, ...) preserves every element of inner, symmetric to LeftJoin; the implementation simply pivots the GroupJoin onto the inner sequence.

`Shuffle` versus Pseudo-Shuffles

Random ordering via OrderBy(_ => Guid.NewGuid()) is widespread but carries two problems.
It generates a GUID per element and pays for an $O(n \log n)$ sort, and the distribution of generated GUIDs as sort keys guarantees no uniformity of the resulting permutation.

Shuffle uses Fisher–Yates, producing each permutation with equal probability in a single $O(n)$ pass.

var deck = Enumerable.Range(1, 52);

var shuffled = deck.Shuffle().ToArray();
// e.g. [17, 3, 50, 28, ...] (differs per call)

Shuffle is deferred, but like OrderBy it buffers the entire source before yielding the first element.

var query = Enumerable.Range(1, 3).Shuffle();

var first = query.ToArray();  // Source is enumerated and shuffled here
var second = query.ToArray(); // Re-enumerating yields a different order

Because deferred queries re-shuffle on every enumeration, materialize once with ToArray / ToList when a fixed order is needed.
The randomness is non-cryptographic; for lotteries or anything requiring unpredictability, use System.Security.Cryptography randomness instead.

The `IQueryable<T>` Pitfall

Outer joins live next door to database queries, which gives this polyfill a risk the other backports do not have.
It extends Enumerable (IEnumerable<T>), but IQueryable<T> inherits IEnumerable<T>, so the compiler happily applies it to Entity Framework queries too.

What happens then is not a runtime error but silent performance degradation.
With no Queryable counterpart available, the Enumerable polyfill binds, and the join is never translated to SQL — it executes client-side.
Entire tables are transferred and joined in memory, and nothing looks wrong until data volume grows.

For server-side outer joins in database queries below .NET 10, keep writing the provider-translatable GroupJoin(...).SelectMany(..., DefaultIfEmpty()) form.
AsEnumerable only draws the client-evaluation boundary; it does not keep the join on the server.
.NET 10 does add LeftJoin / RightJoin to Queryable as well, but their translatability depends on the provider, and this article's scope is Enumerable only.

Migration Guard

The polyfill is wrapped in #if !NET10_0_OR_GREATER.
LeftJoin, RightJoin and Shuffle do not exist before .NET 10, so the wrong guard breaks compilation. !NETCOREAPP disables the polyfill on every target where NETCOREAPP is defined (.NET Core and .NET 5–9), whereas !NET9_0_OR_GREATER disables it only on net9.0 and later (on .NET 8 the NET9_0_OR_GREATER symbol is undefined, so the polyfill stays active; on .NET 9 it is disabled and fails to compile). Both switch the polyfill off where the operators are missing, so the correct guard is #if !NET10_0_OR_GREATER.
The general rule — disable at and above the version that introduced the methods — is laid out in the .NET 6 backport article.

Caveats

Join direction: LeftJoin preserves every element of the first argument (outer); RightJoin preserves every element of the second (inner). The nullable selector argument is the inner element for LeftJoin and the outer element for RightJoin — null-check before use.
Key equality: the comparer-free overloads use EqualityComparer<TKey>.Default. Pass an IEqualityComparer<TKey> for case-insensitive joins and the like. Delegation from the smaller overloads pins resolution with the named argument comparer: (the same technique used in the ToDictionary backport).
Shuffle cannot handle infinite sequences: the entire source is buffered at enumeration start, so an unbounded sequence never completes.
Compile with C# 9 or later: the nullable annotations on unconstrained type parameters (TInner? / TOuter?) fail with errors such as CS8627 under the .NET Framework 4.8 default LangVersion (7.3). Set <LangVersion>9.0</LangVersion> (or latest) in the .csproj.
No name collisions: these signatures do not exist in .NET Framework, and they differ from Join and OrderBy in name and parameters, so overload resolution is unaffected.

Alternatives / Comparison

Approach	Pros	Cons	Best for
Hand-rolled polyfill (this article)	No dependency; the name states the SQL-equivalent intent	The `IQueryable` misapplication risk must be managed	Mostly in-memory joins and shuffles
Write `GroupJoin` + `DefaultIfEmpty` inline	No extra code; translates under `IQueryable` too	Verbose; easy to get subtly wrong	Outer joins in database queries
Substitute `OrderBy(_ => Guid.NewGuid())`	No extra code	Inefficient; no uniformity guarantee	Small collections where rigor is irrelevant
Adopt MoreLINQ or similar	Implemented and tested	External dependency; API differs from the built-ins	Projects already accepting the dependency
Upgrade to .NET 10	Root fix; `Queryable` versions available	Migration cost	When migration is feasible

Until a .NET 10 migration, the pragmatic split is: polyfill for in-memory collections, classic GroupJoin idiom for database queries.

Summary

.NET 10's LeftJoin, RightJoin and Shuffle promote operations that were standard in SQL — or imitated through pseudo-idioms — to first-class LINQ operators.
The backport rests on three points.

LeftJoin / RightJoin embed the classic GroupJoin + SelectMany + DefaultIfEmpty idiom and use nullable annotations to state which side can be missing
Shuffle performs a uniform Fisher–Yates shuffle, fixing both the inefficiency and the bias of Guid.NewGuid() sorting
The polyfill is Enumerable-only; applied to an IQueryable<T> database query it falls back to client evaluation — keep the classic idiom for database queries

Method	Side preserved	Nullable selector argument	Evaluation
`LeftJoin`	Outer (left)	Inner element `TInner?`	Deferred
`RightJoin`	Inner (right)	Outer element `TOuter?`	Deferred
`Shuffle`	—	—	Deferred (full buffering at enumeration)

Why WPF Validation Errors Are Not Displayed, and Choosing Between IDataErrorInfo and INotifyDataErrorInfo

s-iguchi09 — Mon, 14 Sep 2026 16:54:09 +0000

Originally published at s-iguchi09.github.io.
A Japanese version is also available.

Overview

A required-field check is in place, yet the TextBox never turns red.
The symptom splits into two variants.
In one, a breakpoint in the validation code is never hit; in the other, validation clearly runs and Validation.GetHasError returns true, but the screen does not change.

Neither is a defect in the validation logic.
WPF validation is split into three independent parts: the path that produces an error, the place that stores it, and the place that draws it.
When one of them is missing, the other two keep working correctly while the UI stays silent.

This article breaks the "no error shown" symptom into those three stages, isolates each cause, and compares ValidationRule, IDataErrorInfo, INotifyDataErrorInfo, and exception-based validation.
One more symptom is covered alongside them: all three stages hold, yet the message alone is missing, which is the documented behavior of the default ErrorTemplate.
Every behavior and default value described here was measured on .NET 10 / Windows 11.

Prerequisites / Environment

Framework: .NET 6 or later / WPF (behavior verified on .NET 10 / Windows 11)
Language: C# 12 or later / XAML (samples use collection expressions; on targets whose default language version is C# 11 or earlier, such as net6.0, read [] as new() and the spread element [.. messages] as new List<string>(messages))
Target features: Binding validation (Validation attached properties, ValidationRule subclasses, IDataErrorInfo, INotifyDataErrorInfo, ValidatesOnExceptions)
Architecture: MVVM, with the view model holding validation results
Other constraints: the default ErrorTemplate is the baseline; custom templates are covered in the implementation section

Problem

Three TextBox controls are stacked in one panel against the same state, an empty required name.
Only the binding syntax and the interface implemented by the view model differ.
The validation logic is identical in all three cases: an empty string yields exactly one "required" error.

<StackPanel>
    <!-- Bound to a view model that implements IDataErrorInfo -->
    <TextBox x:Name="Plain"
             Text="{Binding Name, UpdateSourceTrigger=PropertyChanged}" />

    <!-- Same view model, with ValidatesOnDataErrors added -->
    <TextBox x:Name="WithFlag"
             Text="{Binding Name, UpdateSourceTrigger=PropertyChanged,
                    ValidatesOnDataErrors=True}" />

    <!-- Bound to a view model that implements INotifyDataErrorInfo -->
    <TextBox x:Name="Notify"
             Text="{Binding Name, UpdateSourceTrigger=PropertyChanged}" />
</StackPanel>

For the comparison, each TextBox receives its own DataContext.

Plain.DataContext = new DataErrorAccount();     // implements IDataErrorInfo
WithFlag.DataContext = new DataErrorAccount();  // same type
Notify.DataContext = new NotifyErrorAccount();  // implements INotifyDataErrorInfo

DataErrorAccount and NotifyErrorAccount are view models that return the same required-field check through IDataErrorInfo and INotifyDataErrorInfo respectively; their definitions are omitted here.
When all three are displayed at once, the default error indication, a red border, appears on the lower two only.

Default error indication for the same "name is empty" state. Only the binding syntax and the interface implemented by the view model differ. The label above each TextBox was added to the figure to identify the corresponding binding (produced on .NET 10 / Windows 11).

For the top TextBox, Validation.GetHasError stays false and Validation.Errors is empty.
A breakpoint in the IDataErrorInfo indexer is never hit.

The two controls that do show a red border have a problem of their own.
Validation.Errors holds the message, but no message reaches the screen.

There is also a configuration in which not even the border appears.
In an application that replaces the ControlTemplate of its Window, Validation.GetHasError returns true and Validation.Errors contains an entry, yet the UI is completely unresponsive to the error.

The Three Stages, and Where It Stops

WPF validation consists of three independent stages, all of which must hold before anything reaches the screen.

Production — a validation rule associated with the binding runs and creates a ValidationError.
Storage — the ValidationError is added to Validation.Errors on the binding target element, and Validation.HasError becomes true.
Rendering — Validation.ErrorTemplate is drawn on the adorner layer of that element.

Stage 2 is handled by the binding engine, so the stages that application code can leave incomplete are 1 and 3.
The sections below separate the symptoms by which of the two is missing.

Stage 1: no rule is associated with the binding

This stops at stage 1.
Implementing IDataErrorInfo does not by itself take part in validation.
The indexer this[string columnName] is called only once a DataErrorValidationRule has been added to the binding.
ValidatesOnDataErrors is the shorthand that adds that rule, and its default value is false.

The activation requirements and the measured default behavior of each approach are as follows.

Validation approach	Rule recorded on the error	Required setting	Default	Error present on initial display
Custom `ValidationRule`	The custom class	Add to `Binding.ValidationRules`	Inactive unless added	No by default; yes with `ValidatesOnTargetUpdated="True"`
`IDataErrorInfo`	`DataErrorValidationRule`	`ValidatesOnDataErrors="True"`	`False`	Yes
`INotifyDataErrorInfo`	`NotifyDataErrorValidationRule`	`ValidatesOnNotifyDataErrors` (on by default)	`True`	Yes
Type conversion failure	Internal conversion rule	None	Always active	—
Exception thrown by a setter	`ExceptionValidationRule`	`ValidatesOnExceptions="True"`	`False`	—

ValidatesOnNotifyDataErrors is the only one that defaults to true.
That is why a view model implementing INotifyDataErrorInfo produces a red border even when the binding itself declares nothing.

INotifyDataErrorInfo also differs in how the error comes into being.
NotifyDataErrorValidationRule.Validate reports success regardless of the value passed to it; in the measured run IsValid was true even for null and an empty string.
The error itself is whatever the view model returns from GetErrors, which the binding engine reads and then keeps in step with through ErrorsChanged notifications to update Validation.Errors.
The rule serves as the marker that appears in RuleInError on the resulting ValidationError.

That read follows a fixed order.
The binding engine consults HasErrors first and calls GetErrors only when it returns true.
In the measured run, an implementation whose GetErrors returned a message displayed nothing and never had GetErrors called at all while HasErrors returned false.
A false result clears any notify errors already recorded, and the check repeats on every ErrorsChanged.
Implementing HasErrors independently of the per-property validation results is therefore enough on its own to produce a view model that holds errors the UI never shows.

Behavior on initial display differs by approach.
DataErrorValidationRule and NotifyDataErrorValidationRule both reported an error before a single character was typed.
A custom ValidationRule, by contrast, was not called when the binding was attached; Validate ran only at the first source update.
This difference explains why a custom rule stays silent when a required field is empty at startup.

The property behind the difference is ValidationRule.ValidatesOnTargetUpdated, which decides whether the rule also runs when the target is updated, that is, when the binding is established and when the source value changes.
In the measured run, the built-in DataErrorValidationRule and NotifyDataErrorValidationRule both returned true, while the default for a custom ValidationRule was false.
Specifying ValidatesOnTargetUpdated="True" makes a custom rule validate from startup as well: the rule was called immediately after launch and then re-evaluated on every change of the source value.

To establish this stage, activate the approach in use.
A design built on IDataErrorInfo specifies ValidatesOnDataErrors="True" on the binding.
INotifyDataErrorInfo is active by default, allows several messages per property, and can report results that arrive asynchronously, such as a server lookup. Choose it when several messages or asynchronous validation are needed.

Stage 3: there is no adorner layer

This stops at stage 3.
Validation.ErrorTemplate does not modify the target control itself; it is drawn on top of it, on the adorner layer.
The most common provider of that layer is AdornerDecorator, which the default ControlTemplate of Window contains.

Replacing the window template with a custom one and omitting AdornerDecorator removes the rendering surface.
In the measured run, a template containing only a ContentPresenter made AdornerLayer.GetAdornerLayer return null, and nothing appeared even though Validation.HasError was true.
Adding a single AdornerDecorator to the same template made the layer resolvable and attached one adorner.

`Window.ControlTemplate`	`Validation.HasError`	`AdornerLayer.GetAdornerLayer`	Red border on screen
Default	`true`	Resolved	Shown
Replaced, without `AdornerDecorator`	`true`	`null`	Not shown
Replaced, with `AdornerDecorator`	`true`	Resolved	Shown

The error is produced and stored correctly, so nothing looks wrong from logs or from HasError.
That asymmetry is what makes this cause hard to locate.

The window template is not the only source of a layer.
An AdornerDecorator placed anywhere in the visual tree creates a new layer for the subtree beneath it.
The following content sits inside a Window whose template omits AdornerDecorator.

<StackPanel>
    <TextBox Text="{Binding Name, UpdateSourceTrigger=PropertyChanged}" />

    <AdornerDecorator HorizontalAlignment="Left">
        <TextBox Text="{Binding Name, UpdateSourceTrigger=PropertyChanged}" />
    </AdornerDecorator>
</StackPanel>

Both TextBox controls bind to the same property of the same view model and hold the same validation error.
The only difference is whether an AdornerDecorator wraps them.

Only the lower control, wrapped in an AdornerDecorator, draws a red border. Before the capture, Validation.HasError was confirmed to be true on both and AdornerLayer.GetAdornerLayer to return null for the upper one, so the difference comes from the rendering surface rather than from the error itself (produced on .NET 10 / Windows 11).

AdornerDecorator is not the only provider.
The ScrollContentPresenter inside a ScrollViewer carries a layer as well.
In the measured run, a TextBox placed inside a ScrollViewer drew its red border even under a Window template that omits AdornerDecorator.
Results therefore diverge between the inside and the outside of a ScrollViewer within one screen, and the symptom can surface as "only some fields lack the border".
When the template has been replaced but the symptom does not reproduce, check whether the control sits inside a ScrollViewer.

To establish this stage, something above the target element must supply an AdornerLayer.
Including AdornerDecorator when the Window template has been replaced is the usual remedy, but as noted above, inside a ScrollViewer the ScrollContentPresenter supplies the layer and that alone is enough.

Before stage 1: the source has not been updated yet

This concerns when stage 1 is reached.
As described earlier, the two built-in rules have ValidatesOnTargetUpdated set to true, so they are also evaluated when the binding is established and when the source value changes.
Input typed by the user, however, is validated only when the value is transferred from the target to the source.
The default UpdateSourceTrigger for TextBox.Text is LostFocus, so typing alone updates neither the source nor the validation state of that input.
In the measured run, clearing a TextBox that started with a valid value left Validation.HasError at false until focus moved away.

This applies to IDataErrorInfo and, as in the implementation below, to an INotifyDataErrorInfo that validates inside its setters.
The latter follows ErrorsChanged on the view model, but in that arrangement the event is raised by the property setter, and the setter is invoked by the source update.
With UpdateSourceTrigger=Explicit the effect is stronger: in the same arrangement the validation state did not change until UpdateSource was called.
An implementation that raises ErrorsChanged independently of the source update, such as one that reports when an asynchronous lookup completes, is not bound by this.

Which stage a case stops at can be told apart by reading Validation.HasError, the Validation.Errors count, and the number of adorners separately.
The figure below records those for a TextBox bound to a source that always reports an error.

Figure: A table of HasError, the Errors count, and the adorner count per validation setup. IDataErrorInfo alone gives False and 0 errors. Turning on ValidatesOnDataErrors gives True, 1, and 1. INotifyDataErrorInfo gives True, 1, and 1 by default. ValidationRules gives True, 1, and 1. Setting ErrorTemplate to null keeps True and 1 but drops the adorner count to 0.

Measured on .NET 10 / Windows 11 with a TextBox bound to a source that always reports an error. adorners is the count returned by AdornerLayer.GetAdorners.

The diagram is rendered in the original article.

The first row shows 0 errors. Implementing IDataErrorInfo is not enough to reach stage 1 without ValidatesOnDataErrors.
The second row turns it on: one error appears, and one adorner is drawn.

INotifyDataErrorInfo behaves differently, as the third row shows. Its counterpart ValidatesOnNotifyDataErrors defaults to enabled, so implementing the interface is enough to take part in validation.
The two interfaces differing in their default is part of what makes this hard to diagnose.

The last row is a case that reaches stage 3 and stops there. HasError is True and Errors still holds one entry, but the adorner count is 0.
The error is held and simply not drawn. A value that is invalid without any red outline appearing corresponds to this row.

To get past this point, specify UpdateSourceTrigger=PropertyChanged on the TextBox.Text binding to report results while the user is still typing.

Implementing All Three Stages

With the three in place, supply an ErrorTemplate that renders the message.
The default template draws only a red border and never shows the contents of Validation.Errors.

The first piece is a base class that stores validation results.
INotifyDataErrorInfo is designed to return a set of messages per property name, so a dictionary keeps the implementation small.

// With ImplicitUsings disabled, System and System.Collections.Generic are also required.
using System.Collections;
using System.ComponentModel;
using System.Runtime.CompilerServices;

public abstract class ValidatableBase : INotifyPropertyChanged, INotifyDataErrorInfo
{
    private readonly Dictionary<string, List<string>> errors = [];

    public bool HasErrors => errors.Count > 0;

    public IEnumerable GetErrors(string? propertyName) =>
        propertyName is not null && errors.TryGetValue(propertyName, out List<string>? list)
            ? list
            : Array.Empty<string>();

    public event PropertyChangedEventHandler? PropertyChanged;

    public event EventHandler<DataErrorsChangedEventArgs>? ErrorsChanged;

    protected void SetProperty<T>(ref T field, T value, [CallerMemberName] string? propertyName = null)
    {
        if (EqualityComparer<T>.Default.Equals(field, value))
        {
            return;
        }

        field = value;
        PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(propertyName));
        Validate(propertyName!);
    }

    protected void SetErrors(string propertyName, IReadOnlyList<string> messages)
    {
        if (messages.Count == 0)
        {
            errors.Remove(propertyName);
        }
        else
        {
            errors[propertyName] = [.. messages];
        }

        ErrorsChanged?.Invoke(this, new DataErrorsChangedEventArgs(propertyName));
        PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(nameof(HasErrors)));
    }

    protected abstract void Validate(string propertyName);
}

ErrorsChanged must be raised when an error is cleared, not only when one is added.
Omitting that leaves the red border in place.
The change notification for HasErrors supports binding the enabled state of a save button directly to that property.
Driving CanExecute of an ICommand instead requires a separate trigger for re-evaluation, such as CommandManager.InvalidateRequerySuggested, because the notification alone does not re-query the command (Fixing a RelayCommand Whose CanExecute Does Not Update the Button State in WPF).

The property name passed to SetErrors must match the binding path exactly; the behavior on mismatch is covered in the notes.

A derived class only describes the validation of its own properties.

public sealed class AccountViewModel : ValidatableBase
{
    private string name = string.Empty;

    public AccountViewModel() => Validate(nameof(Name));

    public string Name
    {
        get => name;
        set => SetProperty(ref name, value);
    }

    protected override void Validate(string propertyName)
    {
        if (propertyName != nameof(Name))
        {
            return;
        }

        List<string> messages = [];
        if (string.IsNullOrWhiteSpace(Name))
        {
            messages.Add("Name is required.");
        }
        else if (Name.Length > 20)
        {
            messages.Add("Name must be 20 characters or fewer.");
        }

        SetErrors(nameof(Name), messages);
    }
}

Validate is called from the constructor so that HasErrors is correct from the initial state, which blocks the save operation immediately after startup.

On the XAML side, define an ErrorTemplate that draws the message and apply it through a Style.
AdornedElementPlaceholder marks where the original control sits, and any decoration can be placed around it.

<StackPanel Margin="16">
    <StackPanel.Resources>
        <ControlTemplate x:Key="FieldErrorTemplate">
            <StackPanel>
                <Border BorderBrush="#D13438" BorderThickness="1">
                    <AdornedElementPlaceholder x:Name="Adorned" />
                </Border>
                <TextBlock Margin="2,2,0,0" FontSize="11" Foreground="#D13438"
                           Text="{Binding ElementName=Adorned,
                                  Path=AdornedElement.(Validation.Errors)/ErrorContent}" />
            </StackPanel>
        </ControlTemplate>

        <Style TargetType="TextBox">
            <Setter Property="Validation.ErrorTemplate" Value="{StaticResource FieldErrorTemplate}" />
            <Setter Property="Margin" Value="0,0,0,22" />
        </Style>
    </StackPanel.Resources>

    <TextBox Width="240" HorizontalAlignment="Left"
             Text="{Binding Name, UpdateSourceTrigger=PropertyChanged}" />
</StackPanel>

The parentheses in AdornedElement.(Validation.Errors) denote an attached property, and the trailing /ErrorContent refers to the current item of the collection, which by default is the first error.
Running this XAML with an AccountViewModel as its DataContext rendered Name is required. under the TextBox right after startup and Name must be 20 characters or fewer. once 21 characters were entered; entering a valid value removed the adorner entirely.

The bottom margin in the Style reserves space for the message.
Adorners take no part in layout, so without that margin the message overlaps the element below it.

Notes

The default ErrorTemplate does not display a message. It draws only a red border on the adorner layer. In the measured run, the ToolTip of the failing TextBox stayed null. Displaying the message requires either replacing the ErrorTemplate or setting ToolTip from a Style trigger on Validation.HasError.
Adorners do not expand the layout. Measuring ActualHeight of the parent panel with and without an error produced the same value. An ErrorTemplate that grows vertically therefore overlaps the elements below unless space is reserved in advance.
(Validation.Errors)[0].ErrorContent reports a binding error when the error clears. A path that addresses the first element by index is re-evaluated the moment the collection becomes empty, which logged System.Windows.Data Error: 17 to the output window. The display itself clears correctly, so the trace is easy to miss. Rewriting the path as /ErrorContent, which refers to the current item, keeps the same display and produces no trace. How to read output window messages is covered in Reading WPF Binding Errors and Diagnosing Them with the Output Window.
Mode=OneWay does not validate user input, and a red border once shown never clears. OneWay has no target-to-source transfer, so typed input never becomes subject to validation. That does not mean validation never runs. Through ValidatesOnTargetUpdated described above, the rules were evaluated under OneWay both when the binding was established and when the source property changed, producing a red border for an invalid value. The problem is that no user action clears that border: typing a valid string into a TextBox bound with OneWay left Validation.HasError at true. A field switched to OneWay for display purposes therefore keeps its error indication permanently.
Assigning to the target of a OneWay binding from code removes the binding. After a plain assignment to TextBox.Text, BindingOperations.GetBinding returned null and the red border disappeared. OneTime behaves the same way. User input and SetCurrentValue both keep the binding intact, so only assignment from code produces this result.
An ErrorsChanged property name that differs from the binding path suppresses the display. Raising ErrorsChanged with Namee while the binding path was Name left Validation.HasError at false even though HasErrors was true. Using nameof instead of string literals prevents this.
Validation results settled asynchronously must be applied on the UI thread. The binding engine subscribes to ErrorsChanged to update Validation.Errors, so that notification has to be raised on the UI thread. When results are settled by background work, move the whole SetErrors call — the dictionary update and both notifications — onto the UI thread through the Dispatcher.
The Validation.Error attached event is not raised by default. Handling errors outside the visual layer, for logging or for blocking navigation, requires Binding.NotifyOnValidationError to be True. The default is False, and without it the handler is never invoked.
Exceptions thrown by a setter are swallowed by default. Feeding an invalid value to a view model whose setter throws ArgumentOutOfRangeException left Validation.HasError at false without ValidatesOnExceptions, and the value was not updated. With ValidatesOnExceptions="True", ExceptionValidationRule caught the exception and Exception.Message became the error content. Messages from the ArgumentException family carry a suffix such as (Parameter 'value'), which is rarely acceptable as user-facing text.
Only type conversion failures surface without any setting. Typing abc into a TextBox bound to an int property produced an error with neither ValidatesOnExceptions nor any validation rule in place, because the binding engine treats a conversion failure as a validation error. That message is generated by the framework and localized to the running UI language, appearing as Value 'abc' could not be converted. under en-US, so replacing it with domain wording requires a custom ValidationRule or an IValueConverter.
A custom ValidationRule receives the value before conversion. The default ValidationStep is RawProposedValue, and Validate received a string even though the binding targeted an int property. Validating it as a number requires parsing inside the method or setting ValidationStep="ConvertedProposedValue".
DataGrid cells behave differently depending on the column type. For columns where the framework creates the editing control at run time, such as DataGridTextColumn, the official documentation states that Validation.ErrorTemplate cannot be used the way it is with simple controls and that no dedicated error template exists for cells. Feedback then goes through DataGridBoundColumn.EditingElementStyle per cell and DataGrid.RowValidationErrorTemplate per row. A DataGridTemplateColumn, by contrast, carries a hand-written editing control in CellEditingTemplate, and setting Validation.ErrorTemplate on that control drew the message inside the cell being edited. EditingElementStyle is a member of DataGridBoundColumn and does not exist on this column type. Switching controls between display and edit modes is covered in Switching Controls Between Display and Edit Modes in WPF DataGrid Cells.
Validation timing follows UpdateSourceTrigger. Whether results appear while typing or after focus leaves is a decision about update timing, not about presentation. The differences between the values are covered in Controlling When TextBox Input Reaches the Source with UpdateSourceTrigger in WPF. Driving the update from the view when Explicit is chosen is covered in Calling TextBox UpdateSource from the View in WPF: Implementation and Pitfalls.

Alternatives / Comparison

The four approaches that produce errors compare as follows.

Approach	Activation	Multiple messages per property	Deferred or async validation	Best suited for
Custom `ValidationRule`	Add to `ValidationRules`	No (only one entry reaches `Validation.Errors`)	No	Input format checks kept inside the view
`IDataErrorInfo`	`ValidatesOnDataErrors="True"`	No (a single `string`)	No	Existing code already built on `IDataErrorInfo`
`INotifyDataErrorInfo`	Active by default	Yes	Yes, reported later through `ErrorsChanged`	New implementations where the view model owns validation
`ValidatesOnExceptions`	`ValidatesOnExceptions="True"`	No	No	Domain models that enforce invariants in setters

Registering several custom ValidationRule objects still yields at most one entry in Validation.Errors, because no rule is evaluated after an earlier one fails.
Carrying several messages in a single error is possible instead, since ValidationResult.ErrorContent is typed as object and accepts a collection.
Doing so requires a display side that can render a collection, such as an ItemsControl; binding ErrorContent to TextBlock.Text as the implementation above does would show the type name.

Being active by default is an advantage of INotifyDataErrorInfo and, at the same time, a path for unintended validation.
Once a view model base class implements the interface, validation is enabled even where nothing is written on the individual bindings.
Disabling it for a specific binding requires an explicit ValidatesOnNotifyDataErrors="False".

Several approaches can be active at once.
Combining IDataErrorInfo with INotifyDataErrorInfo accumulated two entries in Validation.Errors in the measured run.
Adding a custom rule at the RawProposedValue step to that configuration and making it fail, however, removed the DataErrorValidationRule entry.
The UpdatedValue step sits later on the target-to-source validation path, and the path stops at the first failing step.
NotifyDataErrorValidationRule occupies the same UpdatedValue step, yet its entry survived, because that error is supplied from the state the view model holds through ErrorsChanged and is therefore maintained independently of that path.
An ErrorTemplate that shows only the first entry therefore depends on this evaluation order for which message appears, so keeping to a single approach is easier to reason about unless the display requirements demand otherwise.

Summary

Start from the value of Validation.GetHasError when an error fails to appear.

false — either no validation rule is associated with the binding, or the typed input has not reached the source yet. Check ValidatesOnDataErrors="True" for IDataErrorInfo, and the entry in ValidationRules for a custom rule. Specify UpdateSourceTrigger=PropertyChanged to react while the user types.
true with nothing on screen — the rendering surface is missing. Include AdornerDecorator if the Window template has been replaced.
A red border but no message — that is the behavior of the default ErrorTemplate. Supply a custom template containing AdornedElementPlaceholder and display (Validation.Errors)/ErrorContent.

Choose the approach on these criteria.
For new implementations where the view model owns validation, adopt INotifyDataErrorInfo.
Use a custom ValidationRule only when an input format check belongs inside the view, and combine ValidatesOnExceptions when the domain model enforces its invariants in setters.
For existing code built on IDataErrorInfo, check first that ValidatesOnDataErrors="True" has not been omitted.

Fixing the Cross-Thread Exception When Updating an ObservableCollection in WPF

s-iguchi09 — Fri, 11 Sep 2026 16:26:05 +0000

Originally published at s-iguchi09.github.io.
A Japanese version is also available.

Overview

By default, modifying an ObservableCollection<T> bound to an ItemsControl from a thread other than the UI thread throws a NotSupportedException (registering BindingOperations.EnableCollectionSynchronization, described below, lifts this restriction).
The message reads along the lines of "This type of CollectionView does not support changes to its SourceCollection from a thread different from the Dispatcher thread" (the exact wording varies by .NET version and locale).
This article explains that the exception comes from the thread affinity of the CollectionView rather than the collection itself, and it organizes the fixes based on BindingOperations.EnableCollectionSynchronization and the Dispatcher, along with the criteria for choosing between them.

Prerequisites / Environment

Framework: .NET 6 or later / WPF (the same applies to .NET Framework 4.5 and later)
Language: C# / XAML (the code samples use a target-typed new (= new();, C# 9 or later); on C# 8 or earlier, use an explicit type such as = new ObservableCollection<string>();)
Target controls: ObservableCollection<T>, ItemsControl (including ListBox, DataGrid, ListView), CollectionView
Architecture: applicable to both MVVM and code-behind
Assumption: the collection is updated on a background thread (Task.Run or a worker thread)
Verification environment: .NET 10 / Windows 11 (the measured results in this article were obtained here)

Problem

Modifying a bound collection directly from a background thread raises an exception.
The following example adds items to an ObservableCollection<T> from work started with Task.Run.
File.ReadLines (from System.IO) is used as a stand-in data source; it enumerates a file's lines lazily.
The snippets in this article are members of a ViewModel class and assume the namespaces System.Collections.ObjectModel, System.IO, System.Threading.Tasks, System.Windows, and System.Windows.Data.

public ObservableCollection<string> Items { get; } = new();

private async Task LoadAsync(string path)
{
    await Task.Run(() =>
    {
        foreach (var line in File.ReadLines(path))
        {
            // Add from a non-UI thread throws NotSupportedException
            Items.Add(line);
        }
    });
}

When Items is bound to ItemsControl.ItemsSource, the Add call reaches the CollectionView through a CollectionChanged notification.
Because that notification arrives from a non-UI thread, the CollectionView throws the exception.

Figure: A three-lane diagram of the data flow between threads. The first lane shows a CollectionChanged notification arriving directly at the CollectionView from a background thread and raising an exception. The second shows EnableCollectionSynchronization: the change stays on the background thread while the notification is queued and applied asynchronously to the UI thread's shadow copy. The third shows the Dispatcher moving the collection operation itself onto the UI thread.

The exception is raised not when the collection is touched, but when the change notification reaches the CollectionView. The two fixes work differently. EnableCollectionSynchronization makes the CollectionView participate in the same synchronization mechanism and applies queued notifications asynchronously to the shadow copy it keeps for the UI thread — the mutation itself may stay on the background thread. The Dispatcher instead marshals the collection operation onto the UI thread.

The diagram is rendered in the original article.

Cause / Background

ObservableCollection<T> itself is not thread-safe, but that is a separate matter: the direct cause of this NotSupportedException is the CollectionView that WPF routes collection access through when displaying it.
The official documentation states that both the ItemsControl and the CollectionView have affinity to the thread on which the ItemsControl was created, that using them on a different thread is forbidden, and that doing so throws an exception.
In effect, this restriction extends to the bound collection as well.

Most WPF objects derive from DispatcherObject and carry thread affinity to their creating thread, which is normally the UI thread.
The CollectionView also derives from DispatcherObject and, by default, does not allow its bound collection to be changed from another thread.
As a result, when a CollectionChanged notification arrives from a non-UI thread, the CollectionView throws NotSupportedException because it does not permit cross-thread changes.
The root of the problem is therefore not that the collection was touched on another thread, but that the UI-thread-owned CollectionView cannot receive a change notification originating from a different thread.

Measured: the Outcome Depends on Whether the Collection Is Bound

The distinction is visible by performing the same operation on an ObservableCollection<T> that is not bound to anything.
The table below records the result of calling Add from a background thread, varying whether the collection is bound and which countermeasure is applied.

Figure: A table of results from calling Add on a background thread. An unbound ObservableCollection raises no exception. Bound to an ItemsControl it raises NotSupportedException. Both Dispatcher.Invoke and EnableCollectionSynchronization raise no exception. Only the EnableCollectionSynchronization row was notified while the lock was held.

Measured on .NET 10 / Windows 11 by calling ObservableCollection<string>.Add from inside Task.Run. The first row is a collection bound to nothing; the remaining rows are bound to ItemsControl.ItemsSource and displayed in a window. The last column gives how many of the CollectionChanged notifications fired while Monitor.IsEntered reported the lock as held, out of the total.

The diagram is rendered in the original article.

An unbound collection can be modified from a background thread without an exception.
If ObservableCollection<T> itself carried thread affinity, that row would fail as well.
The exception appears only once the collection is bound to ItemsControl.ItemsSource and a CollectionView sits in between, which confirms that the constraint belongs to the CollectionView.

Note that the absence of an exception on the unbound row does not mean the collection is thread-safe.
ObservableCollection<T> provides no protection against concurrent access, so competing updates still corrupt it in other ways.
What the row establishes is narrower: the source of NotSupportedException is the binding target.

The last column reports whether the lock was held at the moment CollectionChanged fired.
Only the EnableCollectionSynchronization row reads 1/1, meaning the change and its notification happen inside the same lock.
The other rows read 0/1, with the notification raised outside any lock.

That 1/1 is the result for a configuration where the application wraps the Add in a lock.
It shows that the lock handed to EnableCollectionSynchronization is still held when the notification arising from that Add is raised.
Registering alone does not place notifications inside the lock; wrapping the Add in the same lock is the application's responsibility.

Two Core Approaches

There are two approaches.

Marshal to the UI thread with the Dispatcher — run the collection mutation itself on the UI thread. This is simple and easy to apply to existing code.
Use BindingOperations.EnableCollectionSynchronization — provide a lock in the application and register it with WPF, which allows direct modification from a background thread. This is less likely to saturate the UI thread even under heavy updates.

The former moves changes onto the UI thread; the latter lets WPF safely take in changes made on another thread.

Marshal to the UI thread with the Dispatcher

Move the collection mutation to the UI thread with Dispatcher.Invoke (or InvokeAsync).
Using Application.Current.Dispatcher obtains the UI thread Dispatcher even from a view model.
This assumes a single UI thread; in an application with multiple UI threads, Application.Current.Dispatcher refers to the main thread and may not own the bound CollectionView, so capture the Dispatcher associated with the bound ItemsControl (or its CollectionView) instead.

private async Task LoadAsync(string path)
{
    var dispatcher = Application.Current.Dispatcher;
    await Task.Run(() =>
    {
        foreach (var line in File.ReadLines(path))
        {
            // Add runs on the UI thread, so no exception occurs
            dispatcher.Invoke(() => Items.Add(line));
        }
    });
}

Because the mutation runs on the UI thread, no affinity violation occurs in the CollectionView.
Invoking per item causes many round-trips to the UI thread, however, so processing several items within a single Invoke is preferable when items can be added in batches.

Share a lock with EnableCollectionSynchronization

Provide a lock object and register it with WPF by calling EnableCollectionSynchronization on the UI thread.
From then on, all application-side modifications must be protected by that same lock.

private readonly object _lock = new();
public ObservableCollection<string> Items { get; } = new();

public ViewModel()
{
    // Call on the UI thread and before using the collection on another thread
    BindingOperations.EnableCollectionSynchronization(Items, _lock);
}

private async Task LoadAsync(string path)
{
    await Task.Run(() =>
    {
        foreach (var line in File.ReadLines(path))
        {
            lock (_lock)
            {
                Items.Add(line);
            }
        }
    });
}

Once EnableCollectionSynchronization is called, the CollectionView accesses the collection using the registered lock and maintains a "shadow copy" for the UI thread.
Change notifications are queued as they arrive and applied when the UI thread has the opportunity to do so.
This allows Add to be called directly from a background thread.
As required by the documentation, the call must occur on the UI thread and before the collection is used on another thread (or attached to the control), whichever is later.

How to Choose

The two core approaches above, plus a variant and a way to avoid the problem entirely, make four in all. Which one applies is settled by the volume and frequency of the updates.

Occasional updates in small numbers call for Dispatcher.
It needs no extra setup and touches little of the existing code. The cost of a per-item round-trip to the UI thread does not matter at low counts.

Heavy, frequent updates from another thread call for EnableCollectionSynchronization.
Running a large number of per-item synchronous Invoke calls saturates the UI thread and reduces responsiveness. Sharing a lock removes those round-trips by allowing direct modification from the background.

A custom synchronization mechanism such as a semaphore calls for the callback overload.
It lets WPF wait on something other than a lock. This is the most complex to implement.

Work that can apply all its changes at once calls for batching on the UI thread.
This avoids producing a cross-thread modification in the first place. The benefit of doing the work in the background shrinks, but no synchronization design is needed.

Comparing the Approaches

Approach	Pros	Cons	Best suited for
`Dispatcher.Invoke` / `InvokeAsync`	No extra setup; simple and easy to retrofit	Per-item round-trips can strain the UI thread	Low update frequency and volume; occasional add or remove
`EnableCollectionSynchronization` (simple lock)	Direct modification from the background; less UI pressure	Requires consistent locking; slightly more design effort	High-volume, high-frequency updates on another thread
`EnableCollectionSynchronization` (callback)	Allows non-lock mechanisms such as semaphores	Most complex to implement	A design that already has a custom synchronization mechanism
Batch on the UI thread	Avoids the threading issue entirely	Loses the benefit of background work	Work that can apply all changes at once after gathering

Notes

Protect all application access with the same lock: the lock passed to EnableCollectionSynchronization must guard every read and write in the application, not only WPF's access. Leaving any path unlocked can race with the CollectionView.
Atomicity of change and notification: a change (such as Add) and its CollectionChanged notification must be atomic. ObservableCollection<T> guarantees this as long as all changes are protected by the same synchronization.
Timing of registration and disabling: call both EnableCollectionSynchronization and DisableCollectionSynchronization on the UI thread. To use the same collection on multiple UI threads, register it separately on each.
UI elements remain UI-thread-only: this fix relaxes only access to the bound collection. Manipulating a DependencyObject, such as a control, directly from another thread remains disallowed.
A worker started with new Thread keeps the process alive: unlike Task.Run, it is a foreground thread by default, so a worker left updating the collection prevents the process from exiting even after the window closes. Diagnosis and remedies are covered in Diagnosing a WPF Process That Stays Alive After the Window Closes — ShutdownMode and Foreground Threads.

Summary

The exception raised when a bound ObservableCollection<T> is modified from another thread comes from the thread affinity of the CollectionView, not the collection.

The deciding factor is the volume and frequency of the updates. Marshal to the UI thread with Dispatcher for occasional ones; share a lock with EnableCollectionSynchronization for heavy, frequent ones.
In every case, design with the understanding that UI elements themselves remain UI-thread-only, and that only collection access is relaxed.

Why a WPF ScrollViewer Does Not Scroll and How to Fix It

s-iguchi09 — Thu, 10 Sep 2026 15:04:56 +0000

Originally published at s-iguchi09.github.io.
A Japanese version is also available.

Overview

The WPF ScrollViewer shows scrollbars and enables scrolling when its content is larger than the available viewport.
When a ScrollViewer is placed inside a StackPanel, however, the scrollbars never appear and the content keeps growing downward regardless of how many items it holds.
This article explains that the behavior comes from how the layout system measures elements, and it organizes the container-based fixes along with the criteria for choosing between them.

Prerequisites / Environment

Framework: .NET 6 or later / WPF
Language: C# / XAML
Target controls: ScrollViewer, StackPanel, Grid, DockPanel
Architecture: applicable to both MVVM and code-behind

Problem

Placing a ScrollViewer inside a vertical StackPanel and filling it with many items often results in no scrollbar; the content extends past the visible area instead.

<StackPanel>
    <TextBlock Text="Header" />
    <ScrollViewer VerticalScrollBarVisibility="Auto">
        <StackPanel>
            <!-- many items -->
        </StackPanel>
    </ScrollViewer>
</StackPanel>

Even though VerticalScrollBarVisibility="Auto" is set, the ScrollViewer expands to the full height of its content and no scrollbar is shown.

The same header and 12 items rendered inside regions of identical height. On the left the ScrollViewer sits inside a StackPanel: no scrollbar appears and the content is clipped at the bottom of the region. On the right it sits in a * row of a Grid, so a scrollbar appears and the remaining items are reachable.

Cause / Background

The cause lies in the available size that the StackPanel passes to its children during measurement.
In its stacking direction, which is height for a vertical panel, a StackPanel measures each child with an infinite available size.
The official documentation notes that a StackPanel does not constrain its children in the direction it stacks.

A ScrollViewer shows a scrollbar only when its content is larger than the height it is given.
When the StackPanel passes an infinite height, the ScrollViewer requests exactly the height needed to fit all of its content, so no overflow occurs.
No scrollbar appears, and the ScrollViewer itself grows to the full height of its content.

The root of the problem is therefore not the ScrollViewer but the surrounding StackPanel, which never constrains the height.

The difference can be confirmed by changing only the parent layout and reading the heights off the ScrollViewer.

Figure: A table of Extent, Viewport, and Scrollable heights plus scrollbar visibility per parent layout. Inside a StackPanel the viewport equals the extent at 800, Scrollable is 0, and the scrollbar is Collapsed. Inside a Grid or DockPanel the viewport is 200, Scrollable is 600, and the scrollbar is Visible.

Measured on .NET 10 / Windows 11 with a ScrollViewer holding 40 rows of 20px each (800px total) inside a parent constrained to 200px. Nothing differs between the rows except the parent layout.

The diagram is rendered in the original article.

Inside the StackPanel, ViewportHeight equals ExtentHeight at 800. Although the parent is constrained to 200px, the ScrollViewer still claims the height its full content needs.
ScrollableHeight is therefore 0 and the scrollbar stays Collapsed.

With a Grid or a DockPanel, ViewportHeight settles at 200 and the remaining 600 becomes ScrollableHeight.
As the last row shows, a StackPanel produces the same result once the ScrollViewer is given an explicit height. What matters is that a constraint reaches it.

Solution

Place the ScrollViewer in a container that constrains its height.
Specifically, put it in a Grid row sized with * (star), let a DockPanel fit it into the remaining space, or give it an explicit Height or MaxHeight.
A finite height is then passed to the ScrollViewer, and a scrollbar appears once the content exceeds that height.

Implementation

Place it in a star-sized Grid row

Split the Grid into a fixed-size row and a * row that fills the remaining space, and put the scrollable ScrollViewer in the * row.

<Grid>
    <Grid.RowDefinitions>
        <RowDefinition Height="Auto" />
        <RowDefinition Height="*" />
    </Grid.RowDefinitions>

    <TextBlock Grid.Row="0" Text="Header" />

    <ScrollViewer Grid.Row="1" VerticalScrollBarVisibility="Auto">
        <StackPanel>
            <!-- many items -->
        </StackPanel>
    </ScrollViewer>
</Grid>

The * row receives the parent's remaining height, so the ScrollViewer is given a finite height.
When the content exceeds that height, the scrollbar appears automatically.

Fit it into the remaining space with a DockPanel

A DockPanel expands its last child into the remaining area through LastChildFill, which is enabled by default.
Dock the header to the top and place the ScrollViewer as the last child.

<DockPanel>
    <TextBlock DockPanel.Dock="Top" Text="Header" />

    <ScrollViewer VerticalScrollBarVisibility="Auto">
        <StackPanel>
            <!-- many items -->
        </StackPanel>
    </ScrollViewer>
</DockPanel>

The last child without a DockPanel.Dock value fills the remaining area, so the height of the ScrollViewer is constrained.

Notes

VerticalScrollBarVisibility="Disabled" turns scrolling off: setting Disabled prevents scrolling in that direction through user interaction. To hide the scrollbar while keeping scrolling, use Hidden instead.
Avoid nesting scrollable controls directly: placing a control with its own scrolling, such as a ListBox, directly inside a ScrollViewer can make the mouse wheel act on the wrong element. A ListBox already scrolls internally, so it is better given a height-constrained layout, such as a * row of a Grid, than wrapped in an outer ScrollViewer.
Physical versus logical scrolling: ScrollViewer.CanContentScroll defaults to false, giving physical, pixel-based scrolling; when it is true, scrolling is logical, by item. The standard ListBox template sets it to true, so a data-bound ListBox scrolls logically and its VirtualizingStackPanel virtualizes items. That virtualization is lost only if CanContentScroll is forced to false, so avoid that for long lists.

Alternatives / Comparison

Container	Scrolling behavior	Suited for
`StackPanel` (vertical)	Does not constrain height, so the `ScrollViewer` does not scroll unless given an explicit `Height` or `MaxHeight`	Short content that needs no scrolling
`Grid` with a `*` row	Passes the remaining height; scrolls when content overflows	Screens that separate headers or footers from a variable area
`DockPanel` (`LastChildFill`)	Fits into the remaining area; scrolls when content overflows	Screens combining edge-docked elements with a main area
Explicit `Height` / `MaxHeight`	Scrolls once the specified height is exceeded	A partial list with a fixed height cap

Summary

A StackPanel passes an infinite height to its children in the stacking direction, so a ScrollViewer inside it cannot detect overflow and does not scroll.
The root of the problem is the surrounding container that fails to constrain the height, not the ScrollViewer itself.

The selection criteria are as follows.

To separate headers or footers from a variable area: place the ScrollViewer in a * row of a Grid. Rows can be assigned by role, which makes the layout intent explicit.
To combine edge-docked elements with a main area: use a DockPanel and place the ScrollViewer as the last child in the remaining space.
To cap only the height of a partial list: set MaxHeight and scroll once that height is exceeded.

In every case, the key is a layout that passes a finite height to the ScrollViewer.

How to Prevent SelectedItems from Appearing Lost in a Virtualized WPF ListBox

Why WPF Style Triggers and DataTriggers Do Not Apply — Dependency Property Value Precedence

s-iguchi09 — Wed, 09 Sep 2026 14:13:42 +0000

Originally published at s-iguchi09.github.io.
A Japanese version is also available.

Overview

A Trigger or DataTrigger declared in Style.Triggers sometimes has no visible effect even though its condition is met.
The common assumption is a broken binding or a type mismatch in the trigger condition, but a frequent cause is that the trigger fires correctly and its value is simply outranked by a higher-precedence input.
This article explains the cause in terms of dependency property value precedence, shows how to repair markup that carries a local value, and gives criteria for choosing among the available fixes.

Prerequisites / Environment

Framework: .NET 6 or later / WPF (the precedence rules are identical on WPF for .NET Framework 4.x)
Language: C#
Target feature: Trigger / DataTrigger / MultiTrigger declared in Style.Triggers
Default theme: Aero2 (the Fluent theme available from .NET 9 differs from what is described below in both the standard control colors and the structure of the default templates)
Architecture: applicable to both MVVM and code-behind

Problem

Consider a Style with a DataTrigger that changes the background of a frame according to a validation state.

<Window.Resources>
    <Style x:Key="StatusBox" TargetType="Border">
        <Style.Triggers>
            <DataTrigger Binding="{Binding HasError}" Value="True">
                <Setter Property="Background" Value="#FFD4D4" />
            </DataTrigger>
        </Style.Triggers>
    </Style>
</Window.Resources>

<Border Style="{StaticResource StatusBox}" Background="White">
    <TextBlock Text="HasError = True" />
</Border>

When HasError becomes true, the background of this Border stays White.
The binding resolves correctly and no binding error appears in the Output window (for reading those messages, see Reading WPF Binding Errors and Diagnosing Them with the Output Window).
The same result occurs with a property trigger such as Trigger Property="IsMouseOver", so the trigger type is not the cause.

Cause / Background

A WPF dependency property can receive values from several inputs: local values, styles, templates, and inheritance.
Which one becomes the effective value is decided by dependency property value precedence, and a higher-precedence input silences every lower one.

The order is as follows, highest precedence first.

Rank	Source of the value	Example
1	Property system coercion	`CoerceValueCallback`
2	Active animations, or animations with a `Hold` behavior	`Storyboard`
3	Local value	A XAML attribute or property element, `SetValue`, or a `Binding` / `StaticResource` / `DynamicResource` written on the element
4	`TemplatedParent` template property values	Elements created by a `ControlTemplate` or `DataTemplate`
5	Implicit styles	Applies to the `Style` property only
6	Style triggers	`Style.Triggers`
7	Template triggers	`ControlTemplate.Triggers` / `DataTemplate.Triggers`
8	Style setter values	A `Setter` directly under `Style`
9	Default (theme) styles	Theme style triggers, then theme style setters
10	Inheritance	Inheritable properties such as `FontSize`
11	Default value from dependency property metadata	The default value in `PropertyMetadata`

The problem lies entirely in the gap between rank 3 and rank 6.
A value written as a XAML attribute, such as Background="White", is a local value at rank 3 and therefore outranks a style trigger at rank 6.
The trigger condition is evaluated and its Setter is applied to that lower rank, but the effective value remains the local value, so nothing changes on screen.

The part that is easy to miss is that a Binding or a DynamicResource written directly on the element also counts as a local value.
Writing Background="{Binding NormalBrush}" only defers evaluation of the value; its precedence is still rank 3, and a style trigger cannot win against it.

A Setter directly under Style, on the other hand, sits at rank 8, below the trigger at rank 6.
Supplying the default through a setter rather than a local value therefore restores the intended relationship.

This precedence can be confirmed by displaying the elements and reading DependencyPropertyHelper.GetValueSource.
The figure below records the result under varying conditions.

Figure: A table of the effective Border.Background and where the value came from. With a local value it stays white at Local; once the default moves to a Setter the trigger color applies at StyleTrigger; with the trigger unmet it is white at Style; and after ClearValue removes the local value the trigger color applies at StyleTrigger.

Measured on .NET 10 / Windows 11. HasError varies per row: it is False on the trigger not met row and True on the others. The value in parentheses is the BaseValueSource returned by DependencyPropertyHelper.GetValueSource.

The diagram is rendered in the original article.

On the row where the value does not change, BaseValueSource is Local. That is why the trigger value never replaces it.
Moving the default into the Setter changes the source to StyleTrigger, and the trigger color becomes the effective value.
Clearing the local value with ClearValue produces the same result, which confirms the local value is the cause.

Solution

Remove the local value from the target element and move the default into a Setter inside the Style.
The default then comes from rank 8 and the conditional value from rank 6, so the trigger wins whenever its condition holds.

Only the property that the trigger writes to is affected.
Setting unrelated properties such as Margin or Width as local values on the element causes no interference.

Implementation

The following markup places two Border elements one above the other under the same style: one keeps its local value, the other takes its default from the setter.
Both reference the same StatusBox style, and the relevant difference is whether Background is present as a local value (the Margin on the lower one only separates the two vertically and has no bearing on the trigger).

<Window.Resources>
    <Style x:Key="StatusBox" TargetType="Border">
        <Setter Property="Background" Value="White" />
        <Setter Property="BorderBrush" Value="#9AA4B2" />
        <Setter Property="BorderThickness" Value="1" />
        <Setter Property="Padding" Value="18,6" />
        <Style.Triggers>
            <DataTrigger Binding="{Binding HasError}" Value="True">
                <Setter Property="Background" Value="#FFD4D4" />
            </DataTrigger>
        </Style.Triggers>
    </Style>
</Window.Resources>

<StackPanel>
    <!-- The local value remains, so the trigger background is not applied -->
    <Border Style="{StaticResource StatusBox}" Background="White">
        <TextBlock Text="HasError = True" />
    </Border>

    <!-- The default moved into the setter, so the trigger background is applied -->
    <Border Style="{StaticResource StatusBox}" Margin="0,12,0,0">
        <TextBlock Text="HasError = True" />
    </Border>
</StackPanel>

The HasError used in the trigger condition is a property on the view model assigned to DataContext.
It implements INotifyPropertyChanged so that runtime changes reach the trigger.

public sealed class ValidationViewModel : INotifyPropertyChanged
{
    private bool _hasError;

    public bool HasError
    {
        get => _hasError;
        set
        {
            if (_hasError == value)
            {
                return;
            }

            _hasError = value;
            PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(nameof(HasError)));
        }
    }

    public event PropertyChangedEventHandler? PropertyChanged;
}

Assigning this view model to the DataContext of the Window propagates changes of HasError to the DataTrigger.
With a plain property that raises no change notification, the trigger is never re-evaluated when the value changes.

Rendering this markup with HasError set to true shows the difference directly.

The result with HasError set to True. The upper border keeps Background as a local value and does not pick up the trigger color; the lower one takes its default from the Setter, so the trigger color is applied. The labels on the left were added to the figure to show how the two Border declarations differ (captured on .NET 10 / Windows 11).

Precedence also depends on how a value is assigned from code-behind.
The three statements below all target Background, but each stores the value at a different rank.

// Becomes a local value, so style triggers no longer affect Background on this element
border.Background = Brushes.White;

// Changes the effective value without writing a local value (a trigger can still take over)
border.SetCurrentValue(Border.BackgroundProperty, Brushes.White);

// Removes an existing local value, restoring the setter or trigger value
border.ClearValue(Border.BackgroundProperty);

SetCurrentValue is a special assignment that does not appear in the precedence list: it changes the current value without overwriting the source of the value.
It suits cases where a temporary value is needed without discarding an existing binding or trigger.
It only avoids creating a local value, however, and does not remove one that is already set.
While a local value remains on the target property the effective value does not change, so it has to be removed with ClearValue first.
ClearValue removes only the local value, so whichever remaining input ranks highest — a theme style, for instance — becomes the effective value.

Notes

ClearValue also removes a binding or a DynamicResource. Calling it on a property that carries only a binding, with no literal local value, discards the binding itself. To supply a default through a binding, write the Binding in the Value of a Setter instead of on the element. To express the trigger condition itself through a binding, use the Binding property of a DataTrigger, which is of type BindingBase. A Binding is accepted in that condition binding and in Setter.Value, but not in the Value of a Trigger or DataTrigger, which holds the value being compared against.
Assigning a local value replaces a binding. A plain assignment to a property that holds a binding replaces the deferred value outright. A later ClearValue call does not restore the binding. Updating a dependency property of a UserControl from inside the control with a plain assignment triggers the same replacement and detaches the binding set by the caller, whereas SetCurrentValue preserves it (see Binding to a WPF UserControl's Own Dependency Property from Inside the Control).
Triggers in a theme style, and in its ControlTemplate, lose to local values as well. Setting Foreground as a local value on a Button suppresses the trigger that greys out the text when the button is disabled. Depending on how the default theme is implemented, that trigger sits at rank 7 (template triggers) or rank 9 (theme styles), but either way it ranks below a local value at rank 3. Verify that the standard state feedback of a control is not being broken.
If a trigger still has no visible effect after the local value is gone, examine the ControlTemplate. The default template of a standard control may hard-code appearance such as the mouseover background. In that case the trigger wins as a property value but never reaches the rendering, and replacing the template is required.
A one-way binding or a literal value in an ItemContainerStyle setter also loses to a local value on the container. When container state is supplied through a style on an ItemsControl, assigning the same property from code produces a local value, and style values no longer reach that container afterwards. A Mode=TwoWay binding in the setter is the exception: the binding survives and the assigned value is written back to the source. The concrete impact on IsSelected and IsExpanded of TreeViewItem is covered in Selecting and Expanding a WPF TreeView Node from Code, and Why SelectedItem Is Read-Only.
The same precedence does not apply to the Style property itself. A Style written on the element is an explicit style with local-value precedence (rank 3), while a style applied from a resource whose key matches the element type is an implicit style at rank 5. When neither is present, the default (theme) style applies at rank 9. An implicit style is not applied to an element that already has an explicit style.
Resource evaluation timing is a separate issue. A StaticResource that is swapped at runtime and never updates is a matter of evaluation timing rather than precedence (see Why StaticResource Changes Are Not Reflected in WPF and How to Fix It). The two problems should not be conflated.

Alternatives / Comparison

Approach	Pros	Cons	Best suited for
Move the default into a `Setter`	Stays entirely in XAML and cannot invert the precedence	Harder to give each element a different default	The default choice in most situations
Assign with `SetCurrentValue`	Creates no local value, so triggers keep working	Requires code-behind	Applying a temporary value at runtime
Remove the local value with `ClearValue`	Leaves the existing XAML untouched	Also removes bindings, and the call timing must be managed	Clearing a local value applied at runtime
Replace the `ControlTemplate`	Controls even the appearance that a template hard-codes	Verbose, and does not follow theme updates	A default template that fixes the appearance
Start an animation from `EnterActions`	Rank 2, so it overrides a local value	Stopping and rewinding must be managed, and animating the `Color` of an unfrozen shared brush also changes every other element that references it	State changes that need a transition effect

Summary

A style trigger that appears broken is often not a mistake in the trigger itself; a local value on the target property is a frequent cause.
Local values sit at rank 3, style triggers at rank 6, and style setters at rank 8, and that ordering alone explains the behavior.

Selection criteria are as follows.

The default is written in XAML: remove the attribute from the element and move it into a Setter in the Style. This has the fewest side effects and should be considered first.
The value changes at runtime from code-behind: use SetCurrentValue instead of a plain assignment. Because it does not overwrite the value source, a trigger that fires later still applies. It has no effect on a property that already carries a local value, so clear that with ClearValue first.
A local value is already in place: clear it with ClearValue, keeping in mind that any binding goes with it. Supply the default from a Setter if one is needed.

Confirming that the target property carries no local value, and keeping every default in a Setter, removes this class of problem at design time.

Controls with Custom Styles Fall Back to the Old Look Under the WPF Fluent Theme

s-iguchi09 — Tue, 08 Sep 2026 16:14:33 +0000

Originally published at s-iguchi09.github.io.
A Japanese version is also available.

Overview

After the Fluent theme is introduced into an existing WPF application, some controls may keep their previous squared-off appearance instead of adopting the Fluent look.
The symptom appears on controls that carry a Style which is not chained to the Fluent style through BasedOn.
An implicit style such as <Style TargetType="Button"> is the most common way an application ends up in that state without the author noticing.
Setting Style="{x:Null}" to opt out of style application leaves the same legacy look.
No exception is raised, no warning appears, and the output window stays silent, so the theme setup itself is easily mistaken for the cause.

This article explains the behavior from how the Fluent theme is delivered to controls, and presents the fix based on BasedOn.
It also documents the placements where BasedOn is written but never resolved, using a results table produced by measurement.

Prerequisites / Environment

Framework: WPF on .NET 9 / .NET 10 (net9.0-windows / net10.0-windows)
OS: Windows 11 (standard colors; high contrast is out of scope)
Theme activation: the ThemeMode property, or merging the Fluent.xaml resource dictionary directly
Target: styles declared in Application.Resources, Window.Resources, or a separate resource dictionary file
Architecture: the behavior is identical for MVVM and code-behind

ThemeMode exists on both Application and Window, so the theme can be set for the whole application or per window.
The results table below includes combinations whose result depends on which one carries the setting.

The pack URI for merging Fluent.xaml directly is the following.

pack://application:,,,/PresentationFramework.Fluent;component/Themes/Fluent.xaml

Assign this URI to the Source of a ResourceDictionary.
With ThemeMode, that markup is unnecessary.
In measurement, setting ThemeMode merged the resolved Fluent.Light.xaml or Fluent.Dark.xaml automatically.

ThemeMode is published as an experimental API.
Every implementation in this article sets it as a XAML attribute, so no suppression is required, but as what's new in WPF for .NET 9 states, accessing it from code produces error WPF0001.
In that case, suppress it with <NoWarn>$(NoWarn);WPF0001</NoWarn> in the project file, or with #pragma warning disable WPF0001.

Problem

Enabling the Fluent theme takes a single attribute.
Setting ThemeMode on the Application element in App.xaml gives the whole application the Fluent appearance.
The problem appears when the existing App.xaml already carries an implicit style.
The following App.xaml applies the Fluent theme while widening the padding of Button as before.

<Application x:Class="MyApp.App"
             xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
             StartupUri="MainWindow.xaml"
             ThemeMode="Light">
  <Application.Resources>
    <Style TargetType="Button">
      <Setter Property="Padding" Value="16,6" />
    </Style>
  </Application.Resources>
</Application>

The style only adds Padding, and neither the template nor the colors are touched.
Even so, the Button does not adopt the Fluent appearance at run time.
A CheckBox placed in the same window renders with the Fluent look, which shows that the theme itself is active.

The state produced by the App.xaml above, with the {x:Type Button} implicit style placed directly in Application.Resources. Captured on Windows 11 / .NET 10 with ThemeMode=Light. The Button has square corners and a gray background, while the untouched CheckBox stays Fluent.

Inspecting this button's template on .NET 10 with ThemeMode=Light shows a CornerRadius of 0 and a background of #FFDDDDDD on the inner Border.
What's new in WPF for .NET 9 states that the default ThemeMode of None uses Aero2.
The measured values match the Aero2 Button on Windows 11 with standard colors, which confirms that no part of the Fluent style is in effect.

Cause / Background

The cause lies in the path through which the Fluent theme reaches a control.

Fluent is delivered as implicit styles, not as a theme style

The earlier WPF themes such as Aero2 are applied as the theme style of a control.
Dependency property value precedence ranks the theme style as the weakest source among styles, with values from the application's own style layered above it.
Measurement confirms that a control carrying an implicit style that sets nothing but Padding still receives the Aero2 template.
Unless OverridesDefaultStyle is set to true, a theme style keeps supplying the template even when the application assigns Style.

The Fluent theme does not use that path.
The reference for the Application.ThemeMode property states that setting the property loads the Fluent theme dictionaries into the application resources.
As far as style delivery is concerned, Fluent arrives as a resource dictionary merged into the resources of the element that carries ThemeMode rather than as a theme style.
The reference for the Window.ThemeMode property likewise states that setting it on a Window loads the Fluent theme dictionaries into that window's resources.
The dictionary also holds many brushes and numeric resources; the implicit styles keyed by values such as {x:Type Button} are one part of it.

This difference is observable in measurement.
A control with Style="{x:Null}", which explicitly opts out of style application, renders with the Aero2 appearance even while the Fluent theme is active.
If Fluent were supplied as a theme style, clearing Style would leave the Fluent appearance in place.

A style with the same key hides the Fluent style

The key of the Fluent implicit style is exactly the key that <Style TargetType="Button"> produces in application code: {x:Type Button}.
When the same key exists in two places, resource lookup rules determine which one is used.
In both placements described below, the application style is the one selected.

For a style placed directly in Application.Resources, the outcome follows the precedence between a dictionary and the dictionaries merged into it.
The article on merged resource dictionaries states that when a key is defined in the primary dictionary and also in a merged dictionary, the resource returned comes from the primary dictionary.
ThemeMode adds Fluent as a merged dictionary, so the style written directly in Application.Resources takes precedence.

For a style placed in an inner scope such as Window.Resources, the outcome follows scope proximity.
The article on styles and templates explains that the search for an element's style walks up the element tree, then looks in the application resources, and consults the theme last.
Window.Resources is examined before Application.Resources, so the application style is selected.

In both cases the application style does not extend the Fluent style; it replaces and hides it entirely.
Once hidden, the Fluent template is no longer supplied, and the control falls back to the built-in WPF theme style, Aero2.
That is why a style adding nothing but Padding discards the whole Fluent appearance.

All of this describes a style written without BasedOn. Where the original can be inherited through BasedOn, the template survives while your own setters still apply.
The last two rows of the figure below measure that for a TextBox style placed in Window.Resources.
Depending on where the style lives, though, BasedOn itself may fail to resolve. The Solution section covers that condition.

Which source supplied the template can be told apart by the named parts inside it.
The Fluent TextBox template holds a DeleteButton; the classic theme does not.

Figure: A table of the named parts in the TextBox template per way the theme reaches the control. DeleteButton is present on the row where ThemeMode is set and on the row merging Fluent.xaml directly. An implicit style without BasedOn removes DeleteButton on either route, leaving only PART_ContentHost, while the rows whose implicit style inherits through BasedOn keep DeleteButton on both routes.

Measured on .NET 10 / Windows 11. The Style applied column reports whether the Style property is filled in (an implicit style) or left null (a classic theme style).

The diagram is rendered in the original article.

The point is the second row, where Style applied reads implicit style. Setting ThemeMode alone fills in the Style property, showing that Fluent arrives as an implicit style rather than a theme style.
On the first row, without ThemeMode, Style stays null and the template comes from the classic theme style.

On the third row, an application-side implicit style under the same key that carries no BasedOn makes DeleteButton disappear.
Padding reads 8, so the application style did take effect. It is precisely because it took effect that the Fluent style was replaced and its template lost with it.

The last two rows inherit the original through BasedOn. On both routes — ThemeMode and a direct merge of Fluent.xaml — Padding reads 8 just the same and DeleteButton survives.

What this figure measures is an implicit TextBox style placed in Window.Resources.
A Button, or a style placed directly in Application.Resources, lands elsewhere; the table in the Solution section covers those.

Solution

Add BasedOn to the style so that it inherits the Fluent implicit style.
Writing BasedOn="{StaticResource {x:Type Button}}" layers the local Setter elements on top of the Fluent style.

This markup carries one constraint that must be respected.
When the key passed to BasedOn is the same as the style's own key, and that key also exists in a dictionary merged into the dictionary declaring the style (including nested merged dictionaries), BasedOn is left unresolved and stays null.
No exception is raised, and the legacy appearance remains.
This condition was derived from measurement on .NET 9 and .NET 10; it is not a description of how StaticResource resolves internally.

Declaring an implicit style directly inside Application.Resources meets that condition.
ThemeMode adds the Fluent dictionaries as merged dictionaries of the very Application.Resources that declares the style.

The rule above states only when the reference fails, and the converse does not hold: avoiding the condition does not guarantee that BasedOn reaches Fluent.
As the table below shows, some placements fail to reach Fluent without meeting the condition.

The figure below contrasts placing the style directly in Application.Resources with moving it into a dedicated resource dictionary file, referred to here as Styles.xaml.

Figure: On the left, a style placed directly in Application.Resources, where the path toward Fluent.Light.xaml inside MergedDictionaries is blocked and BasedOn becomes null. On the right, Styles.xaml added to MergedDictionaries, where the style inside it reaches Fluent.Light.xaml in the same MergedDictionaries.

The relationship between the BasedOn target and the dictionary that declares the style. A dashed frame is MergedDictionaries, a white box is a resource dictionary, and the lighter box inside it is a style. On the left the style sits directly in Application.Resources, so the referenced key matches the style's own key and also exists in a dictionary merged into that same dictionary, leaving it unresolved. On the right the style lives in a separate file inside MergedDictionaries, so it reaches the Fluent entry in the same MergedDictionaries. Both set ThemeMode on Application, and both were confirmed on .NET 9 and .NET 10 running Windows 11.

The diagram is rendered in the original article.

A failed reference can be spotted quickly by inspecting the style at run time.
For a style placed in Application.Resources, basedOn below being null means it did not resolve.

Style? style = Application.Current.Resources[typeof(Button)] as Style;
Style? basedOn = style?.BasedOn;

For a style placed in Window.Resources, read the target window's Resources the same way instead of Application.Current.Resources.

This check misses cases, however.
A non-null basedOn can still point at the default theme style rather than at Fluent.
Make the final call by rendering the control and looking for Fluent-specific traits such as rounded corners.

The configuration that reliably inherits Fluent is therefore the following.

Set ThemeMode on Application, not on a Window.
Keep the style out of Application.Resources itself (moving it into a dedicated resource dictionary file and merging that file is the most manageable way to do so).
Do not merge the Fluent dictionary inside that file.
Add BasedOn="{StaticResource {x:Type Button}}" to the style.

Implementation

Move the style into a separate resource dictionary

First, extract the implicit style into Styles.xaml.
Specify {StaticResource {x:Type Button}} for BasedOn so the Fluent style becomes the base.

<ResourceDictionary xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
                    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
  <Style TargetType="Button" BasedOn="{StaticResource {x:Type Button}}">
    <Setter Property="Padding" Value="16,6" />
  </Style>
</ResourceDictionary>

Do not merge the Fluent dictionary into this file.
Merging Fluent.xaml inside Styles.xaml makes the target a merged dictionary of Styles.xaml, and the reference stops resolving.

Merge the dictionary from App.xaml

App.xaml is then limited to setting ThemeMode and merging Styles.xaml.
Keeping the style itself out of Application.Resources is the essential point.

<Application x:Class="MyApp.App"
             xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
             StartupUri="MainWindow.xaml"
             ThemeMode="Light">
  <Application.Resources>
    <ResourceDictionary>
      <ResourceDictionary.MergedDictionaries>
        <ResourceDictionary Source="pack://application:,,,/MyApp;component/Styles.xaml" />
      </ResourceDictionary.MergedDictionaries>
    </ResourceDictionary>
  </Application.Resources>
</Application>

The Fluent dictionary merged by ThemeMode and Styles.xaml become sibling merged dictionaries within Application.Resources.
With this layout, BasedOn resolves to the Fluent implicit style and only the Padding setter is layered on top.
In measurement, the Fluent dictionary added by ThemeMode precedes Styles.xaml, so the ordering issue described later does not arise.
For a file in the same project whose build action is Resource, a relative path such as Source="Styles.xaml" also works.

The state produced by applying the Styles.xaml and App.xaml above as written. Captured on Windows 11 / .NET 10 with ThemeMode=Light. Compared with the previous figure, the Button now has rounded corners and a lighter background. In measurement, the Padding setter survives unchanged in this state.

Placement and resolution results

Whether BasedOn resolves depends on the combination of where the style lives and where Fluent comes from.
The following results were measured for Button on both .NET 9 and .NET 10.
The BasedOn column shows the key passed to BasedOn="{StaticResource ...}".
For the row with x:Key, the keyed style was applied explicitly through Style="{StaticResource ...}", with no implicit {x:Type Button} style placed alongside it.
The table covers only placements where the custom style actually applies to the control; for placements where the custom style never applies at all, see the notes below.

Placement of the style	Source of Fluent	`BasedOn`	Result
Directly in `Application.Resources` (implicit)	`ThemeMode` on `Application`	none	Legacy look
Directly in `Application.Resources` (implicit)	`ThemeMode` on `Application`	`{x:Type Button}`	Legacy look (`BasedOn` is `null`)
Directly in `Application.Resources` (implicit)	`ThemeMode` on `Application`	`DefaultButtonStyle`	Fluent
Directly in `Application.Resources` (with `x:Key`)	`ThemeMode` on `Application`	`{x:Type Button}`	Fluent
Separate file merged into `Application.Resources` (implicit)	`ThemeMode` on `Application`	`{x:Type Button}`	Fluent
`Window.Resources` (implicit)	`ThemeMode` on `Application`	`{x:Type Button}`	Fluent
Separate file merged into `Window.Resources` (implicit)	`ThemeMode` on `Application`	`{x:Type Button}`	Fluent
`Window.Resources` (implicit)	`ThemeMode` on the same `Window`	`{x:Type Button}`	Legacy look (`BasedOn` is `null`)
Separate file merged into `Window.Resources` (implicit)	`ThemeMode` on the same `Window`	`{x:Type Button}`	Legacy look (`BasedOn` is not `null`)
Separate file that merges `Fluent.xaml` itself (implicit)	`Fluent.xaml` in that same file	`{x:Type Button}`	Legacy look (`BasedOn` is `null`)

Each of the three rows where BasedOn becomes null meets the same condition: the key passed to BasedOn matches the style's own key, and that key also exists in a dictionary merged into the dictionary declaring the style.
The row referencing DefaultButtonStyle, whose key differs, and the row whose style carries an x:Key do not meet that condition, so they resolve even though they sit directly in Application.Resources.

The row pairing a separate file merged into Window.Resources with ThemeMode on that same Window, by contrast, keeps the legacy look without meeting the condition.
The dictionary declaring the style in that row is the separate file, and Fluent sits outside it in the merged dictionaries of Window.Resources, so the condition does not apply.
Even so, BasedOn was not null in measurement; it resolved to the default theme style instead of Fluent.
When ThemeMode is set on a Window, moving the style into a separate file is not enough.
Moving ThemeMode up to Application resolves it.
In measurement, both a style directly in Window.Resources and one in a file merged into Window.Resources reached Fluent that way.
Moving the style into Application.Resources itself is a separate matter, and the second row of the table shows that it does not resolve.

Alternative: when the App.xaml structure cannot change

When the file layout is fixed, reference DefaultButtonStyle, which the Fluent theme dictionary provides.
Because that key differs from the style's own {x:Type Button} key, it resolves even directly inside Application.Resources.

<Application.Resources>
  <Style TargetType="Button" BasedOn="{StaticResource DefaultButtonStyle}">
    <Setter Property="Padding" Value="16,6" />
  </Style>
</Application.Resources>

Measurement shows that the Fluent {x:Type Button} style carries no setter of its own and that its BasedOn is DefaultButtonStyle itself.
For Button the two are effectively equivalent, so this form loses no setter.
DefaultButtonStyle is not a documented key and depends on the internal structure of Fluent.xaml, so treat it as a stopgap.
Applying the same approach to another control requires checking that control's key name, and whether its implicit style is equivalent to the style under that key.
In measurement the TargetType of DefaultButtonStyle is ButtonBase, not Button, so the referenced style may target a base type.

Alternative: confining the change to part of the UI

A keyed style resolves BasedOn against {x:Type Button} even directly inside Application.Resources.

<Application.Resources>
  <Style x:Key="WideButton" TargetType="Button"
         BasedOn="{StaticResource {x:Type Button}}">
    <Setter Property="Padding" Value="16,6" />
  </Style>
</Application.Resources>

Because this style does not occupy the {x:Type Button} key itself, the target of the reference is the Fluent implicit style.
A keyed style is not applied automatically, so every control needs an explicit Style="{StaticResource WideButton}".

This form reaches Fluent only as long as no implicit {x:Type Button} style remains directly in Application.Resources.
In measurement, keeping an implicit style alongside it made BasedOn resolve to that implicit style instead, leaving the legacy appearance.
A keyed style applied without BasedOn also falls back to the legacy appearance, just as an implicit one does.

Notes

Nothing reports the failure. An unresolved BasedOn produces no exception and no warning in the output window. Only the rendered appearance reveals it, so verify migrations visually against Fluent-specific traits such as rounded corners.
Set ThemeMode on Application. Setting it per window creates placements where BasedOn resolves to the default theme style rather than Fluent, even with the style moved into a separate file. A separate problem also appears: with ThemeMode on a Window and the custom styles merged into Application.Resources, the appearance does turn Fluent but the custom setters have no effect. The Fluent implicit style that ThemeMode placed in Window.Resources is found before the custom style in the outer Application.Resources, so the custom style never applies. Unless individual windows need different light/dark modes, keep the setting on Application. Note that once Application carries anything other than None, a Window can no longer be set back to None.
Each control type needs its own fix. Implicit style keys are per type, so repairing Button leaves the styles of TextBox or CheckBox untouched. Enumerate the declared styles by type before migrating an existing application.
The set of controls Fluent covers differs by version. What's new in WPF for .NET 10 added styles for controls such as GroupBox. Measurement confirms that the implicit style for GroupBox is absent from Fluent on .NET 9 and present on .NET 10. For a control that Fluent does not style implicitly, BasedOn resolves to the default theme style instead of becoming null, so a null check does not catch it; judge by the unchanged appearance.
Style="{x:Null}" opts out of Fluent. Disabling style application leaves that control with the Aero2 appearance. Review any place that uses {x:Null} to restore a default look before adopting Fluent.
When using ThemeMode, do not merge the Fluent theme dictionaries by hand. The reference for the Application.ThemeMode property recommends against adding the Fluent theme dictionaries manually when the property is set, because the manually added ones take precedence. The same reference notes that ThemeMode also controls the window backdrop and dark mode, so it is not equivalent to merging Fluent.xaml by hand.
The order of merged dictionaries changes the result. As the article on merged resource dictionaries states, when the same key appears twice in one MergedDictionaries, the later entry wins. In measurement, merging Fluent.xaml after the custom styles discarded the custom setters. Place Fluent.xaml before the custom styles when merging it manually.
A direct Fluent.xaml merge follows the Windows theme setting. In measurement, merging Fluent.xaml on a machine set to dark mode loaded the dark dictionary at startup. Whether it follows a theme switch made while the application is running was not verified for this article. To pin the appearance, drop the manual merge and set ThemeMode to Light or Dark. Adding ThemeMode while keeping the manual merge leaves the control colors unpinned, because the manual merge wins.
ThemeMode and Fluent are still changing. ThemeMode remains an experimental API as of .NET 10, and its reference notes that it may be removed in a future version. The Fluent style implementation is also still in progress. The results table above reflects .NET 9 and .NET 10, and later versions warrant a recheck.

Alternatives / Comparison

Approach	Pros	Cons	Best suited for
Separate dictionary with `BasedOn="{StaticResource {x:Type Button}}"`	Relies only on documented markup, and implicit styles keep applying automatically	Requires changing the file layout	The standard case of migrating an existing app to Fluent
`BasedOn="{StaticResource DefaultButtonStyle}"`	Leaves the `App.xaml` structure untouched	Depends on a key that is not documented	A stopgap when the file layout cannot change
Keyed style applied explicitly with `BasedOn`	Limits the scope of the change to the chosen controls	Every usage needs an explicit `Style` reference	Adjusting only certain screens or controls
Keep the existing styles without Fluent	No migration work	Loses the Windows 11 appearance and does not follow the light/dark theme	Applications that already ship a fully custom design

Summary

As far as style delivery is concerned, the Fluent theme arrives as implicit styles inside a resource dictionary rather than as a theme style.
An application style using the same {x:Type Button} key therefore hides the Fluent style, and the control falls back to the Aero2 appearance.

The fix is inheritance through BasedOn="{StaticResource {x:Type Button}}", but when the key passed to BasedOn matches the style's own key and also exists in a dictionary merged into the dictionary declaring the style, BasedOn stays unresolved and the legacy look remains with no error to signal it.
For migrating an existing application, set ThemeMode on Application and make the default structure a dedicated resource dictionary file holding the styles, merged from App.xaml.
Setting ThemeMode per window creates placements where the style is never chained to Fluent, even when it lives in a separate file.
Reference DefaultButtonStyle only when the App.xaml structure cannot be changed, and choose keyed styles with explicit application when the change should stay confined to part of the UI.

DEV Community: s-iguchi09

Binding to the Parent DataContext from Inside a WPF DataTemplate

Overview

Prerequisites / Environment

Problem

Cause / Background

Solution

Implementation

Notes

Alternatives / Comparison

Summary

Related Articles

Expressing SQL Outer Joins in LINQ — Implementing LeftJoin, RightJoin and Shuffle

Overview

Prerequisites / Environment

How SQL Join Clauses Map to LINQ Idioms

Implementation

Using LeftJoin / RightJoin

LeftJoin: Keep Every Outer (Left) Element

RightJoin: Keep Every Inner (Right) Element

Shuffle versus Pseudo-Shuffles

The IQueryable<T> Pitfall

Migration Guard

Caveats

Alternatives / Comparison

Summary

Related Articles

Why WPF Validation Errors Are Not Displayed, and Choosing Between IDataErrorInfo and INotifyDataErrorInfo

Overview

Prerequisites / Environment

Problem

The Three Stages, and Where It Stops

Stage 1: no rule is associated with the binding

Stage 3: there is no adorner layer

Before stage 1: the source has not been updated yet

Implementing All Three Stages

Notes

Alternatives / Comparison

Summary

Related Articles

Fixing the Cross-Thread Exception When Updating an ObservableCollection in WPF

Overview

Prerequisites / Environment

Problem

Cause / Background

Measured: the Outcome Depends on Whether the Collection Is Bound

Two Core Approaches

Marshal to the UI thread with the Dispatcher

Share a lock with EnableCollectionSynchronization

How to Choose

Comparing the Approaches

Notes

Summary

Related Articles

Why a WPF ScrollViewer Does Not Scroll and How to Fix It

Overview

Prerequisites / Environment

Problem

Cause / Background

Solution

Implementation

Place it in a star-sized Grid row

Fit it into the remaining space with a DockPanel

Notes

Alternatives / Comparison

Summary

Related Articles

Why WPF Style Triggers and DataTriggers Do Not Apply — Dependency Property Value Precedence

Overview

Prerequisites / Environment

Problem

Cause / Background

Solution

Implementation

Notes

Alternatives / Comparison

Summary

Related Articles

Controls with Custom Styles Fall Back to the Old Look Under the WPF Fluent Theme

Overview

Using `LeftJoin` / `RightJoin`

`LeftJoin`: Keep Every Outer (Left) Element

`RightJoin`: Keep Every Inner (Right) Element

`Shuffle` versus Pseudo-Shuffles

The `IQueryable<T>` Pitfall