Why StaticResource Changes Are Not Reflected in WPF and How to Fix It

Overview

WPF provides two resource reference mechanisms: StaticResource and DynamicResource.
When a resource referenced with StaticResource is replaced with another object in code at runtime and the UI does not update, the root cause is the difference in when each mechanism resolves its value.
This article explains the internal behavior of both mechanisms and provides criteria for choosing between them.

Prerequisites / Environment

• Framework / Language: .NET 6 or later / WPF / C#
• Architecture: Applicable to both MVVM and code-behind patterns
• Verification environment: .NET 10 / Windows 11
• Also tested on: .NET Framework 4.8.1 (4.8.9363) / Windows 11 (built for .NET Framework 4.8)
  A separate MVVM sample that reproduces the article’s conditions confirmed the four before-and-after rows for StaticResource and DynamicResource in the measured table of the Cause / Background section (the sample uses different colors from the article), with the same results as on .NET 10.
  The two rows that change brush.Color were not measured on .NET Framework.

The figure and table in this article come from displaying a screen in the environment above that references the same resource through both StaticResource and DynamicResource, then swapping the resource at run time.
The following points were confirmed in that environment:

• Before the swap, both sides hold the same value.
• After the swap, the value referenced through StaticResource does not change.
• After the swap, the value referenced through DynamicResource follows it.

Problem

Replacing an entry in a ResourceDictionary at runtime does not always cause the associated control to update its appearance.

For example, the following XAML defines a SolidColorBrush as a StaticResource, and the code-behind replaces it at runtime.

<Window xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
    <Window.Resources>
        <SolidColorBrush x:Key="ThemeColor" Color="SkyBlue" />
    </Window.Resources>

    <Button Background="{StaticResource ThemeColor}" Content="Button" />
</Window>

// Attempt to change the color at runtime
Resources["ThemeColor"] = new SolidColorBrush(Colors.OrangeRed);

Despite the assignment, the button background remains SkyBlue.

Cause / Background

The critical difference between StaticResource and DynamicResource lies in when the resource value is resolved.

How StaticResource Works

StaticResource resolves the resource exactly once, at the moment the XAML is parsed (loaded).
The resolved value is written directly to the property, after which no reference between the property and the resource dictionary is retained.
Consequently, replacing the dictionary entry with another object afterward is invisible to the property.
What the property received, however, is the brush or other object itself. Changing the Color of the same brush, when it is not frozen, does change what the StaticResource side shows (the last two rows of the table below).

Because XAML is parsed top-to-bottom, a resource referenced via StaticResource must be defined before its reference site in the markup.
Violating this order raises a XamlParseException at load time.

How DynamicResource Works

DynamicResource does not resolve the value immediately.
Instead, it records the association between the property and the resource key.
Whenever the corresponding entry in the resource dictionary changes at runtime, WPF detects the change and re-evaluates the property, updating the UI automatically.

The difference can be confirmed by replacing the resource at run time and reading the property back.

Measured on .NET 10 / Windows 11 by reading Border.Background after replacing the entry behind the same key PanelBrush with a red brush at run time, and after changing the same brush’s Color to red without replacing the entry. Nothing else differs between the rows except how the resource is referenced and changed.

Both hold the same value before the swap. The two diverge only afterwards, where the StaticResource side stays white.

Solution

To reflect runtime resource changes in the UI, replace StaticResource with DynamicResource at the affected binding site.

Implementation

Dynamic Theme Toggle with DynamicResource

The following example switches the button background color on each button click by replacing the brush in the resource dictionary.
Because DynamicResource is used, the assignment propagates to the Background property immediately.

<Window x:Class="SampleApp.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
    <Window.Resources>
        <SolidColorBrush x:Key="ThemeColor" Color="SkyBlue" />
    </Window.Resources>

    <StackPanel>
        <Button Background="{DynamicResource ThemeColor}" Content="Target Button" />
        <Button Content="Toggle Theme" Click="OnThemeToggleClick" />
    </StackPanel>
</Window>

private bool _isDark = false;

private void OnThemeToggleClick(object sender, RoutedEventArgs e)
{
    _isDark = !_isDark;
    Resources["ThemeColor"] = _isDark
        ? new SolidColorBrush(Colors.DarkSlateGray)
        : new SolidColorBrush(Colors.SkyBlue);
}

The assignment to Resources["ThemeColor"] is reflected on the Background property without any additional refresh call.

Full Theme Switch via MergedDictionaries

For application-wide light/dark theme switching, a common pattern is to separate each theme into its own ResourceDictionary file and swap the active dictionary at runtime.

Theme file (Themes/Light.xaml):

<ResourceDictionary xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
                    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
    <SolidColorBrush x:Key="Background" Color="White" />
    <SolidColorBrush x:Key="Foreground" Color="Black" />
</ResourceDictionary>

Theme file (Themes/Dark.xaml):

<ResourceDictionary xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
                    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
    <SolidColorBrush x:Key="Background" Color="#1E1E1E" />
    <SolidColorBrush x:Key="Foreground" Color="White" />
</ResourceDictionary>

Theme switching code:

private void SwitchTheme(string themeName)
{
    var uri = new Uri($"Themes/{themeName}.xaml", UriKind.Relative);
    var dict = new ResourceDictionary { Source = uri };

    Application.Current.Resources.MergedDictionaries.Clear();
    Application.Current.Resources.MergedDictionaries.Add(dict);
}

All controls that reference theme resources via DynamicResource update automatically when MergedDictionaries is replaced.
Controls using StaticResource for the same keys will not update.

Notes

• In the theme switching covered here, Freeze matters when an existing Freezable instance is mutated: If Freeze() has been called on a Freezable resource (e.g., a SolidColorBrush), modifying its properties throws an InvalidOperationException.
  Check IsFrozen before mutating an existing instance; if you replace the dictionary entry with a new instance, freezing is typically not an issue.
  Freezing has other effects as well, such as allowing cross-thread access and causing the object to be cloned when it becomes the target of an animation.
• Overusing DynamicResource degrades performance: DynamicResource acts as a deferred expression that looks the value up at runtime and re-evaluates it whenever the resource changes.
  Applying DynamicResource to every resource in a large application can increase memory usage and slow initial rendering.
  Retain StaticResource for values that never change at runtime.
• A resolved resource does not always change the appearance: When the target property carries a local value, the value supplied by a style trigger never becomes the effective value.
  The cause there is dependency property value precedence rather than evaluation timing (see Why WPF Style Triggers and DataTriggers Do Not Apply — Dependency Property Value Precedence).
• Where DynamicResource can be written depends on the kind of value: Even inside Style or ControlTemplate triggers, the Value of a Setter — the value handed to a dependency property — accepts DynamicResource.
  What it cannot be used for is a value that is not a dependency property, the Value (the comparison value) of a Trigger or DataTrigger, and property values of a Storyboard or animation.
  Errors in these cases surface at runtime rather than compile time, so runtime testing is required.

Alternatives / Comparison

Summary

StaticResource fixes the property value at XAML load time; replacing a resource dictionary entry after that point has no effect on the property.
When the value must change at runtime, DynamicResource is required.

Selection criteria:

• Resources that never change at runtime (brand colors, fixed font sizes, standard margins): use StaticResource.
  The performance impact is minimal.
  Definition order alone is not sufficient, though: resolution also fails when the key does not match or when the resource is defined outside a scope reachable from the reference, so verify order, key name, and scope.
• Resources that must change at runtime (theme colors, OS system colors via SystemColors or SystemParameters): use DynamicResource.

The recommended approach is to default to StaticResource and apply DynamicResource only where runtime changes are explicitly required.
This strategy balances maintainability and rendering performance.

Related Articles

• Controls with Custom Styles Fall Back to the Old Look Under the WPF Fluent Theme
• Diagnosing Why Parts of a WPF App Stay Light After Switching ThemeMode at Runtime