Управление ресурсами WPF (кисти и т. Д.)
Обычно я помещаю то, что я считаю основными корневыми ресурсами, такими как фирменные цвета / кисти, шрифты и размеры, в сборку 'distrib'.
Сборки Distrib предназначены для использования в сторонних разработчиках, поэтому они имеют доступ к нашим контрактам, интерфейсам и стилям брендинга.
Затем создаются более сложные ресурсы, которые объявляются «ближе» к тому месту, где они используются.
Я пришел к приложению, которое выросло органически, ошибочно, бессистемно. Странно то, что модули используют ресурсы из основного исполняемого проекта приложения, даже если модули не ссылаются на приложение.
Я предполагаю, что поскольку они «импортируют» все ресурсы в App.xaml, они доступны контексту конструктора псевдо-среды выполнения.
Мой вопрос:
Если это то, как MS разработала это для работы, я все время делал это неправильно, управляя ресурсами, как я делаю систему типов?
Спасибо
Люк
** ОБНОВЛЕНИЕ **
Итак, мне было указано, что хорошо организованные ресурсы не подходят для WPF из-за серьезной проблемы с производительностью (во многом как я обнаружил в большом приложении SL4, над которым работал, но предполагал, что это была вещь SL).
Предполагая, что управление ресурсами таким высокоорганизованным способом все еще может быть выполнено с помощью одной или двух уловок, и что модульные системы часто нуждаются в объединении словарей, я начал изучать возможность использования решения Кристиана Мозера 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)
Похоже, он не понимает URI пакета, что странно, поскольку SharedResourceDictionary просто вызывает исходную реализацию MS в ResourceDictionary, и статическая регистрация схемы URI пакета также не помогает !! Grrr.
Итак, мне нужно взломать, и второй вариант - вбить все в App.xaml и избегать объединения словарей.
Это означает меньшее количество элементов управления / представлений и настройку словаря времени разработки в моей распространяемой библиотеке, который, я полагаю, выполняет работу с app.xaml, к которому у них не будет доступа.
Думаю, в этом есть смысл.
Интересно? Сообщите Microsoft
. Это может быть для Silverlight, но я надеюсь, что люди WPF, возможно, прислушаются, или, по крайней мере, это может исправить одну платформу - я добавил «идею» на сайт UserVoice, за которую вы можете проголосовать .