Есть ли способ использовать StaticResource в библиотеке элементов управления WPF и иметь возможность просмотра во время разработки -?

У меня есть библиотека элементов управления WPF, которая добавляется в приложение Windows Forms. Мы хотим, чтобы элементы управления были локализуемыми, однако я не уверен, как это сделать ПОЛНОСТЬЮ без дублирования кода. Вот чем я сейчас занимаюсь .

По сути, в приложении Windows Forms, прежде чем запустится основное приложение, я создаю экземпляр App.xaml, который находится в приложении Forms (, содержащий мои ссылки на мои ресурсы, которые также находятся в приложении Forms ).. Это отлично работает во время выполнения.

Однако все мои пользовательские элементы управления имеют Content="{StaticResource SomeVariableName}", которые в конечном итоге остаются пустыми. Я могу исправить это, имея app.xaml и соответствующие словари ресурсов в моей библиотеке управления, которые соответствуют тем, что есть в моем приложении Windows Forms. Однако это дублированный код.

Вещи, которые я уже пробовал безрезультатно:

• Создайте экземпляр App.xaml, который находится в библиотеке управления пользователя, из моего приложения форм. Это не работает, потому что URI для моих ресурсов ищут встроенный ресурс, а не мой локальный словарь ресурсов (. Затем я мог бы просто скопировать файлы ресурсов из элемента управления в соответствующее место в моем приложении форм при сборке ). Могу ли я использовать здесь DeferrableContent ? Насколько я мог найти в Интернете, об этом атрибуте и о том, как его следует использовать, не так много.
• Я хотел бы использовать пост-сборки как для приложения, так и для словарей, однако, насколько я могу судить, создание экземпляра приложения является статической ссылкой на скомпилированный файл App.xaml. Таким образом, App.xaml должен находиться в форме как минимум
  • Я попытался создать дубликат App.xaml с переносом в пост-сборку resourcedictionary.xaml.Я решил, что дублированный app.xaml — это нормально, так как это движущая сила, и вы, возможно, не захотите полагаться на один из элементов управления в любом случае (, который возвращается назад и заставляет задуматься, следует ли вам затем иметь App.xaml в контролировать вообще? Если вы не хотите разрешить использование встроенных ресурсов по умолчанию.... )Это тоже не удалось, заявив, что не может найти ресурс, даже если он был размещен там, где должен был указывать URI. Декомпилированный код указывает наUri resourceLocater = new Uri("/WindowsFormsApplication3;component/app.xaml", UriKind.Relative);

Итак, есть ли какой-нибудь способ, чтобы это работало И имело возможность просмотра значений по умолчанию компонента во время разработки И избегало дублирования? Или дублирование нормально в этом случае? Если элемент -моей второй пули выглядит нормально (продублировал App.xaml со сборкой скопированных ресурсов ), как мне заставить его искать не элемент уровня компонента, а вместо этого уровень файла?

Последний вопрос (и я могу опубликовать его отдельно, если нужно ), на который я только что обратил внимание. Мой App.xaml встроен в код, так что в любом случае я не могу создавать новые ResourceDictionaries на лету. Есть какой-либо способ сделать это?

Последний вариант... возможно, лучший? -В любом случае я планирую использовать код Андре ван Хеерварде , поэтому должен ли я просто проверять существование файла и добавлять его как объединенный ресурс на лету? По сути, в моем пользовательском элементе управления есть один App.xaml, который ссылается на встроенный ResourceDictionary по умолчанию. И тогда код ищет соответствующие локализованные ресурсы на лету, которые могут быть относительными путями к файлам? Единственный недостаток, который я вижу здесь, заключается в том, что значение по умолчанию нельзя изменить на лету... что я мог бы, вероятно, даже иметь такой вид в указанном месте (, используя какое-то соглашение ), и предпочесть его встроенному -в одном?

Да, и причина, по которой я не хочу использовать встроенные ресурсы, заключается в том, что конечные пользователи могут добавлять/изменять новые локализованные ресурсы после развертывания сборки.

Я могу добавить код, если он поможет вам лучше представить это.просто дай мне знать.

ОБНОВЛЕНИЕ

Теперь у меня возникла еще одна проблема со стилем, а не только с локализацией.

Вот пример одной из внутренних кнопок на одном из элементов управления:

Еще несколько вещей, о которых я думал/пробовал:

• Я не могу создать app.xaml (, который никогда не будет использоваться )с ResourceDictionary, настроенный как ApplicationDefinitions, не разрешен в библиотечных проектах. Я мог бы встроить это в ресурсы элемента управления, но тогда это всегда будет иметь приоритет над любыми ресурсами уровня приложения, и я потеряю возможность настройки.

Вот случай с подключением , который на самом деле звучит так, как я ищу, однако он не дает никакого реального решения для этого

Решение (за пределами вершины.. которое не работает ), что я думаю о том, что это могло бы сработать (и еще не пробовало ), также кажется, что много работы для чего-то, что, как я думал, должно быть простым. Но я мог бы создать некоторые свойства зависимостей в элементе управления, к которым я могу привязываться, а затем разрешить их переопределение проектом, который будет использовать элемент управления. Как я уже сказал, для довольно простого запроса :)требуется много работы. Будет ли это вообще работать? И что еще более важно, есть ли лучшее, более простое решение, которое мне не хватает?