1

I made a custom control library and made a control named "FlipView" in the root path. Then I removed the style in Generic.xaml and moved it to its own Resource dictionary named FlipView.xaml in the root path. Now I merge that resource dictionary into Generic.xaml using the following code:

<ResourceDictionary.MergedDictionaries>
    <ResourceDictionary Source="pack://application:,,,/FlipView.xaml" />
</ResourceDictionary.MergedDictionaries>

Then I used the control in another wpf project, but it throws a XamlParseException with InnerException saying

Cannot locate resource 'flipview.xaml'.

Why can't it? The Resource Dictionary is in the root path of the control library project.

If I replace the Source property setter with "pack://application:,,,/MyCustomControls;component/FlipView.xaml" (MyCustomControls is the name of my custom control library) it works perfectly fine.

Generic.xaml:

<ResourceDictionary.MergedDictionaries>
    <ResourceDictionary Source="pack://application:,,,/MyCustomControls;component/FlipView.xaml" />
</ResourceDictionary.MergedDictionaries>

Why is this the case?

For the WPF projects, this seems redundant because pack://application,,,/ refers to the root path and WpfAssemblyName;component/ again refers to the root path. Why is it necessary for Generic.xaml?

Edit: I have seen this question but it does not explain why.

Community
  • 1
  • 1
wingerse
  • 3,670
  • 1
  • 29
  • 61

1 Answers1

1

Cause you use a resource file from another assembly and it is necessary to point an assembly name.

As MSDN says:

The pack URI for a resource file that is compiled into a referenced assembly uses the following authority and path:

  • Authority: application:///.

  • Path: The name of a resource file that is compiled into a referenced assembly. The path must conform to the following format:

    AssemblyShortName[;Version][;PublicKey];component/Path

    • AssemblyShortName: the short name for the referenced assembly.
    • ;Version [optional]: the version of the referenced assembly that contains the resource file. This is used when two or more referenced assemblies with the same short name are loaded.
    • ;PublicKey [optional]: the public key that was used to sign the referenced assembly. This is used when two or more referenced assemblies with the same short name are loaded.
    • ;component: specifies that the assembly being referred to is referenced from the local assembly.
    • /Path: the name of the resource file, including its path, relative to the root of the referenced assembly's project folder.

The following example shows the pack URI for a XAML resource file that is located in the root of the referenced assembly's project folder.

pack://application:,,,/ReferencedAssembly;component/ResourceFile.xaml

Update:

To avoid redundant words in address to declare styles in the same assembly, it is possible to declare your style file without pointing out to a library:

<ResourceDictionary.MergedDictionaries>
    <ResourceDictionary Source="FlipView.xaml" />
</ResourceDictionary.MergedDictionaries>

Answer by Clemens:

Take a look at the third figure here. Pack URIs in an application are relative to the application assembly, even if they are used in a library. Your resource is in a referenced assembly, so you'll have to specify its name.

StepUp
  • 36,391
  • 15
  • 88
  • 148
  • No. It is not a referenced assembly. The generic.xaml, the flipview.xaml and flipview.cs are all in the root of the control library assembly. – wingerse May 06 '16 at 15:55
  • 1
    Take a look at the third figure [here](https://msdn.microsoft.com/en-us/library/aa970069(v=vs.100).aspx#The_Pack_URI_Scheme). Pack URIs in an application are relative to the application assembly, even if they are used in a library. Your resource is in a referenced assembly, so you'll have to specify its name. – Clemens May 06 '16 at 16:04
  • StepUp, that doesn't work either. @Clemens, oh, that explains it. StepUp, can you update the answer with Clemens' comment? Or maybe Clemens can add an answer? – wingerse May 06 '16 at 16:11
  • @EmperorAiman it is really interesting, but this address works in my project. I am just merging styles from different xaml files in one resource dictionary in the same library. What error do you see? – StepUp May 06 '16 at 16:14
  • @StepUp, did you make a control library and use it in a wpf application? Try it – wingerse May 06 '16 at 16:18
  • 1
    If the controls are in the WPF assembly, any pack uri works fine. But when it's in a different assembly, I have to apparently include the assembly name – wingerse May 06 '16 at 16:19
  • @EmperorAiman yeh, I have many projects in one solution and one class library is for Resources. **But when it's in a different assembly, I have to apparently include the assembly name** yeap, you are right. If you use style in another assembly, you should add reference to the library and point out the name of the full address of library including name of library – StepUp May 06 '16 at 16:23
  • @EmperorAiman I've made a test project where that there is no error when you declare just name of file without specifying a assembly name. https://onedrive.live.com/redir?resid=D6BDF30773C16E01!2083&authkey=!AJ9ASY0Ni8vUpDk&ithint=file%2crar – StepUp May 06 '16 at 17:57
  • 1
    Which line are you doing it? Specifying pack uri without assembly works fine when I am using files in the same WPF project. But when I need a file in another assembly, I need to specify the file, obviously. But in control libraries, pack uri still have to specify assembly even if the files are in the same control library assembly, unlike the case with WPF assembly where you could leave that part. – wingerse May 06 '16 at 18:19
  • in the following line ` `. OK. I understand you. But what is the name of Project Template to create `Control library`? – StepUp May 06 '16 at 18:30
  • @Clemens I've included your answer to my answer. If you post your answer in this theme, then I'll delete your answer from my reply. Thanks for answer. – StepUp May 06 '16 at 20:37
  • @EmperorAiman I've included Clemens's answer to my reply to simplify future search by other people. – StepUp May 06 '16 at 20:37