Silverlight Resources

Analogy categoryAnalogies

ResourceDictionary and Scoped Lookup

Every FrameworkElement and Application in Silverlight exposes a Resources property, a ResourceDictionary of key-value pairs that can hold anything from a SolidColorBrush to a full Style or DataTemplate. When XAML references {StaticResource SomeKey}, Silverlight walks up the visual tree starting at the element that declared the binding, checking that element's Resources, then its parent's, and so on up to Page and finally Application.Resources, using the first matching key it finds; this scoping means a resource redeclared with the same key at a lower level in the tree shadows one defined higher up, similar to variable scoping in code.

🏏

Cricket analogy: Looking up a StaticResource by walking up the tree is like a young player first checking with their franchise's specific batting coach for technique advice, then escalating to the national selector's guidelines only if the franchise hasn't specified anything, with the closer, more specific source always taking precedence.

Merged ResourceDictionaries

To organize resources across files, a ResourceDictionary supports a MergedDictionaries collection where each entry is another ResourceDictionary, typically loaded from a separate XAML file via Source="/AssemblyName;component/Themes/Colors.xaml"; this lets a team split colors, brushes, and control styles into dedicated files (Colors.xaml, Fonts.xaml, ButtonStyles.xaml) and merge them all into Application.Resources in App.xaml, so every page and control in the application can resolve those shared keys through the same StaticResource lookup chain without each page re-declaring the dictionary.

🏏

Cricket analogy: Merging separate ResourceDictionary files for Colors, Fonts, and ButtonStyles is like a cricket board maintaining separate rulebooks for T20, ODI, and Test formats, then combining the relevant ones into a single reference binder for each specific match official rather than one unmanageable master document.

Embedded Assets: Resource vs Content

Non-XAML assets like images, fonts, and XML data files are added to a Silverlight project with a Build Action of either Resource, which compiles the file directly into the assembly (.xap or .dll) and is accessed via a pack URI such as "/AssemblyName;component/Images/logo.png", or Content, which copies the file alongside the compiled assembly into the output .xap package and is referenced with a relative or absolute URI without the component syntax; Resource is preferred for small assets that must always be present with the assembly, while Content suits larger or frequently updated assets, since Content files can be swapped in the deployed .xap without recompiling the DLL.

🏏

Cricket analogy: Build Action Resource is like a team's official crest sewn permanently into the jersey fabric at the factory, always present and part of the garment itself, while Content is like a sponsor patch that's ironed on separately and can be swapped out for a new sponsor without remaking the whole jersey.

xml

<!-- App.xaml -->
<Application xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
             x:Class="App.App">
    <Application.Resources>
        <ResourceDictionary>
            <ResourceDictionary.MergedDictionaries>
                <ResourceDictionary Source="/App;component/Themes/Colors.xaml" />
                <ResourceDictionary Source="/App;component/Themes/ButtonStyles.xaml" />
            </ResourceDictionary.MergedDictionaries>

            <SolidColorBrush x:Key="AccentBrush" Color="#FF2C7BE5" />
        </ResourceDictionary>
    </Application.Resources>
</Application>

<!-- Usage in a page -->
<Image Source="/App;component/Images/logo.png" Width="64" Height="64" />
<TextBlock Text="Welcome" Foreground="{StaticResource AccentBrush}" />

StaticResource resolves once, at XAML parse time, and does not update if the resource is replaced later at runtime — for scenarios needing runtime theme swapping, resources must be re-applied programmatically (Silverlight lacks WPF's DynamicResource).

Silverlight has no DynamicResource markup extension (unlike WPF); attempting to use it will fail to compile — any resource that needs to change after initial load must be re-fetched and re-applied through code, not through a markup extension.

Resources property (a ResourceDictionary) exists on FrameworkElement and Application, holding any keyed object.
StaticResource lookup walks up the visual tree from the referencing element to Application.Resources, using the first match found.
A resource redeclared at a lower scope shadows one with the same key defined higher in the tree.
MergedDictionaries lets separate ResourceDictionary XAML files be combined into one logical dictionary.
Build Action Resource compiles an asset into the assembly; Build Action Content copies it into the .xap alongside the assembly.
Content assets can be replaced in a deployed .xap without recompiling, unlike Resource assets.
Silverlight has no DynamicResource; runtime resource changes require code, not a markup extension.