WPF pack: / [assemblyName]; component / ... vs pack: // application: ,, / [assemblyName]; component / ...?

pack:/Common;component/Resources/DefaultTheme/DefaultTheme.xaml

This is a technically valid URI, but it is not a valid pack

URI. Parsing it in accordance with the format rules pack

will give:

Package <empty>


URI: Part URI:/Common;component/Resources/DefaultTheme/DefaultTheme.xaml

In fact, you made an absolute URI from the URI part by adding a scheme pack:

. However, without a well-formed package component, the result is not a valid pack

URI. And, interestingly, the class Uri

won't actually parse the original string as an absolute URI; it is being parsed incorrectly as a relative URI and that is part of the reason it works when assigned ResourceDictionary.Source

. Let's take a look at the setter property:

public Uri Source
{
    get { return _source; }
    set
    {
        // ...
        _source = value;

        Clear();

        Uri uri = BindUriHelper.GetResolvedUri(_baseUri, _source);
        WebRequest request = WpfWebRequestHelper.CreateRequest(uri);
        // ...
}

      

        
        
        
      

    

The key lies within BindUriHelper.GetResolvedUri(_baseUri, _source)

. The logic there, which is different from most of the URI handling pack

in WPF, sees that _source

it is not an absolute URI (at least according to the slice Uri

), so it tries to concatenate it with a resolved base URI, which we assume as pack://application:,,,/

. The URIs are concatenated through new Uri(Uri baseUri, Uri relativeUri)

, which only works because it did Uri

not parse the original string as a relative URI correctly. The URI ultimately used for creation WebRequest

is equivalent to:

new Uri(
    new Uri("pack://application:,,,/"),
    new Uri("pack:/Common;component/Resources/DefaultTheme/DefaultTheme.xaml"))

      

        
        
        
      

    

... which produces:

pack://application:,,,/Common;component/Resources/DefaultTheme/DefaultTheme.xaml

      

        
        
        
      

    

And viola, we end up loading resources from a valid package URI, even if we gave it an invalid one.

We know that a "bad" URI works because it accidentally turns into a good one. As to why this same "good" URI does not work in the designer when used directly, this is very curious.

Perhaps you just need to rebuild the project Common

and the project that is trying to merge the resource dictionary. If it still doesn't work, it is possible that yours UserControl.Resources

has different BaseUri

running time in the constructor than at runtime. Let's see if we can figure out what BaseUri

's in development time. Change UserControl

as follows:

<UserControl xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
             ...
             xmlns:m="clr-namespace:System.Windows.Markup;assembly=System.Xaml"
             x:Name="Root">
  <UserControl.Resources>
    <ResourceDictionary">
      <Style x:Key="BaseUriTextStyle" TargetType="TextBlock">
        <Setter Property="Text"
                Value="{Binding ElementName=Root,
                                Path=Resources.(m:IUriContext.BaseUri)}" />
      </Style>
    </ResourceDictionary>
  </UserControl.Resources>

  <TextBlock Style="{StaticResource BaseUriTextStyle}" />
</UserControl>

      

        
        
        
      

    

See what is displayed in the designer. This may give us a clue.