Управление ресурсами WPF (кисти и т.д.)

Обычно я помещаю то, что я считаю конституционными корневыми ресурсами, такими как цвета/кисти, шрифты и размеры бренда в сборке "distrib".

Распределительная сборка предназначена для выхода в сторонние магазины-разработчики, поэтому они имеют доступ к нашим контрактам, интерфейсам и стилям брендинга.

Затем создаются более сложные ресурсы и объявляются "ближе", где они используются.

Я пришел к приложению, которое органично выросло, ошибочно, беспорядочно. Что странно, что модули используют ресурсы из основного исполняемого проекта приложения, хотя модули не ссылаются на приложение.

Я предполагаю, что, поскольку они "импортируют" все ресурсы в App.xaml, они доступны для контекста дизайнера psuedo-runtime.

Мой вопрос

Если это так, как MS разработала его для работы, я делал это неправильно все время, управляя ресурсами, как я делаю систему типов?

Спасибо

Лука

** ОБНОВЛЕНИЕ **

Итак, мне было указано, что хорошо организованные ресурсы - это не путь в WPF из-за серьезной проблемы с производительностью (так же, как я нашел в большом приложении SL4, над которым я работал, но предположил, что это SL вещь).

Предполагая, что управление ресурсами в этом высокоорганизованном виде все же можно выполнить с помощью трюка или двух, и что модульные системы часто должны объединять словари, я начал изучать использование решения Christian Moser SharedResourceDictionary, но у меня возникла проблема при проектировании только время:

System.IO.Packaging.PackUriHelper

The URI prefix is not recognized.
   at System.Net.WebRequest.Create(Uri requestUri, Boolean useUriBase)
   at System.Net.WebRequest.Create(Uri requestUri)
   at MS.Internal.WpfWebRequestHelper.CreateRequest(Uri uri)
   at System.Windows.ResourceDictionary.set_Source(Uri value)
   at CompanyName.Presentation.SharedResourceDictionary.set_Source(Uri value)

Похоже, что он не понимает пакет Uris, который является нечетным, поскольку SharedResourceDictionary просто обращается к исходной реализации MS в ResourceDictionary, и регистрация схемы URI пакета статически не помогает! Хмм.

Так что мне нужно взломать, а второй вариант - разбить все на App.xaml и избежать объединенных словарей.

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

Я думаю, что это имеет смысл.

Интересно? Сообщите Microsoft

Это может быть для Silverlight, но я надеюсь, что пользователи WPF могут слушать или, по крайней мере, могут исправить одну платформу - я добавил "идею" на сайт UserVoice, который вы можете проголосовать.

http://dotnet.uservoice.com/forums/4325-silverlight-feature-suggestions/suggestions/2307678-fix-the-mergeddictionary-perf-problem

Ответ 1