Почему абсолютный uri необходим для объединенных словарей в Generic.xaml?

Рассмотрим файл | Новый проект приложения WPF, содержащий:

  • Новый настраиваемый элемент управления с именем CustomControl1
  • Два новых ресурсных словаря с именем Dictionary1 и Dictionary2

Возьмите созданный стиль из Generic.xaml и переместите его в Dictionary2. Затем объедините Dictionary2 в Dictionary1 и Dictionary1 в Generic следующим образом:

<!--Generic.xaml-->
<ResourceDictionary.MergedDictionaries>
    <ResourceDictionary Source="pack://application:,,,/Themes/Dictionary1.xaml"/>
</ResourceDictionary.MergedDictionaries>

<!--Dictionary1.xaml-->
<ResourceDictionary.MergedDictionaries>
    <ResourceDictionary Source="Dictionary2.xaml"/>
</ResourceDictionary.MergedDictionaries>

Затем добавьте экземпляр CustomControl1 в сетку MainWindow. (Эта часть необходима для воспроизведения проблемы. Проект всегда компилируется отлично - только во время выполнения проблема возникает, и словари должны ссылаться.)

В Dictionary1.xaml я слияния в другом dict в той же папке, поэтому работает простой Source = "Dictionary2.xaml". Однако в Generic.xaml я должен использовать абсолютный URI. Если я изменил выше, чтобы быть Source = "Dictionary1.xaml" без пакета://application stuff, тогда я получаю исключение XamlParseException, вызванное IOException "Невозможно найти ресурс" dictionary1.xaml ", когда он пытается построить MainWindow.

Мой вопрос: Что общего в generic.xaml относительно относительного разрешения URI и почему?

Ответы

Ответ 1

Извините, потому что у меня нет возможности писать комментарии, поэтому я отправляю это как ответ.

У меня такая же ситуация, и все работает отлично для меня. Мне не нужно ставить "pack://application" в путь в Generic.xaml. Но только тогда, когда тип вывода сборки является "Приложением Windows". Для "Библиотека классов" Мне нужно добавить имя сборки в путь (Source="/ClassLibarayAssemblyName;component/Themes/Dictionary1.xaml") becasue без этого. Драйвер WPF пытается искать Dictionary1.xaml в основной сборке приложения.

Целевая структура в обоих случаях - это "Клиентский профиль .NET Framework 4"

Ответ 2

Просто догадаться: generic.xaml также должен быть доступен извне сборок, поэтому это способ гарантировать, что ресурсы можно найти из любого места, используя абсолютные URI. Как я уже сказал, это просто удар в темноте, не уверен.