Resource Lookup Basics
Resources such as Brushes, Styles, and DataTemplates are declared in a ResourceDictionary, typically inside Application.Resources, a Window's or Page's Resources, or a control's Resources collection, and each is given a unique x:Key. Both {StaticResource} and {DynamicResource} look up a value by that key, walking up from the element's own Resources through its logical-tree ancestors until a matching key is found, ending at the Application-level ResourceDictionary if nothing closer matches.
Cricket analogy: It is like a fielding captain checking their own bowling changes first, then the team's standard tactics board, and finally the national team's playbook if no local instruction exists, just as resource lookup walks outward through nested scopes until a key is found.
StaticResource: Resolved Once at Load Time
{StaticResource} resolves the referenced resource once, when the XAML is parsed and the object tree is built. If the resource entry in the dictionary is later replaced at runtime, elements that used {StaticResource} keep the value they originally captured; they do not observe the change. StaticResource is the right choice for resources that never change during the application's lifetime, such as a fixed corner radius or a static brush that is not part of a theme-switching feature, because it avoids the small overhead of maintaining a live subscription.
Cricket analogy: It is like a batting average printed in a matchday program: it reflects the player's stats at print time and does not update if the player scores a century that same afternoon, just as StaticResource captures a value once and never refreshes.
DynamicResource: Live, Re-Evaluated on Change
{DynamicResource} instead creates a live expression that is re-evaluated whenever the resource dictionary entry for that key changes, making it the correct choice for theme-switching, user-configurable accent colors, or any resource that the application intentionally swaps at runtime. The tradeoff is a small performance cost, since DynamicResource must maintain a subscription and re-apply the value on every change, whereas StaticResource has none of that ongoing bookkeeping once the initial lookup succeeds.
Cricket analogy: It is like a live scoreboard app that updates automatically the instant a run is scored, in contrast to the printed program from before, and this constant refreshing does use extra data compared to a static printout, just as DynamicResource trades a little overhead for live updates.
<Application.Resources>
<SolidColorBrush x:Key="AccentBrush" Color="#3F51B5" />
<CornerRadius x:Key="StandardCornerRadius">4</CornerRadius>
</Application.Resources>
<!-- Never changes at runtime: safe to use StaticResource -->
<Border CornerRadius="{StaticResource StandardCornerRadius}" />
<!-- Swapped at runtime by a theme switcher: must use DynamicResource -->
<Button Background="{DynamicResource AccentBrush}" Content="Save" />
<!-- Later, in code-behind, swapping the theme brush -->
Application.Current.Resources["AccentBrush"] =
new SolidColorBrush(Colors.OrangeRed);Using {StaticResource} for a brush that a theme switcher later replaces is a common bug: the app compiles and runs fine, but elements bound with StaticResource simply never change color when the user switches themes, because the reference was locked in at parse time.
- Both extensions look up a resource by x:Key, walking up nested ResourceDictionary scopes to the Application level.
- {StaticResource} resolves once at parse time and never reflects later changes to the dictionary entry.
- {DynamicResource} maintains a live subscription and re-applies the value whenever the dictionary entry changes.
- StaticResource has lower runtime overhead since it needs no ongoing subscription.
- DynamicResource is required for theme switching or any resource intentionally swapped at runtime.
- A resource must already exist in the dictionary when a StaticResource reference is parsed, or it throws; DynamicResource tolerates late-bound resources.
- Choosing StaticResource for a resource that later gets swapped is a common source of UI elements that silently fail to update.
Practice what you learned
1. When does {StaticResource} resolve its referenced value?
2. Which extension should be used for a brush that a runtime theme switcher will replace?
3. In what order does resource lookup search nested ResourceDictionary scopes?
4. What is a key runtime tradeoff of DynamicResource compared to StaticResource?
5. What typically happens if a {StaticResource} key does not exist anywhere in the resource scope chain at parse time?
Was this page helpful?
You May Also Like
Markup Extensions Overview
How XAML's curly-brace syntax defers value creation to parse time through classes that implement MarkupExtension.
x:Static and x:Type
Bridging XAML to CLR code: pulling in static field/property values with x:Static and referencing types themselves with x:Type.
TemplateBinding
The lightweight, one-way markup extension used inside a ControlTemplate to connect template visuals to the templated control's own properties.
Related Reading
Related Study Notes in Microsoft Technologies
Browse all study notesWindows 10 / UWP Development Study Notes
.NET · 30 topics
Microsoft TechnologiesWindows Batch Scripting Study Notes
Batch · 30 topics
Microsoft TechnologiesMFC (Microsoft Foundation Classes) Study Notes
C++ · 30 topics
Microsoft TechnologiesSilverlight Study Notes
.NET · 30 topics
Microsoft TechnologiesWPF (Windows Presentation Foundation) Study Notes
.NET · 30 topics
Microsoft TechnologiesMVVM Design Pattern Study Notes
.NET · 30 topics