I had a post about accessing XAML resources using Pack URI, and actually had the chance to try it out. The format of the pack URI is "pack://authority/path", and there are only 2 valid authority: application:/// and siteoforigin:///, as described in Microsoft's Pack URI documentation.
The path will just point to the resource you want to get; you can include the folder / subfolder, other assemblies (containing the resource), even versions of the assembly. The simplest example they had was:
pack://application:,,,/ResourceFile.xaml
that points to ResourceFile.xaml in the local assembly. What the documentation forget to define however, is what is local assembly; the local assembly is essentially the WPF executable. If you have other XAML in a different assembly, and you have code in that same assembly to load the XAML using Pack URI, you have to treat it as if you're loading from a different assembly.
As an example, if you have a WPFResource.DLL which has a XAML resource (in this case test.xaml) you'd like to load, the code to load it will be as follows:
|
private static void InitializeWPFApplicationResources()
{
Uri uri = new Uri("pack://application:,,,/WPFResource;component/test.xaml");
Application.Current.Resources.Source = uri;
}
|
The Pack URI has to refer to an external assembly - even though test.xaml resides in the same assembly with the executing code. Anytime the pack URI doesn't refer to a different assembly, it will try to load the XAML resource from the executable file - I'm actually surprised with this, since it forces the Uri to always contain the assembly name which can be erroneous (say the assembly gets renamed). Granted you can get around this problem by getting the assembly's name in code.