Как распределять ресурсы/стили в композитном WPF приложении?

Question

[Aleksej]

Проблема/Задача: Имеется композитное (модульное) приложение на WPF с использованием IoC контейнера Unity, без использования каких-либо фреймворков типа Prism.
Имеется три уровня модулей:
- верхний, не зависит ни от кого, содержит инфраструктуру и интерфейсы.
- средний, модули подгружаемые в оболочку. Референцируют только верхний уровень.
- низший, представлят собой оболочку и стартовую точку. Референцирует инфраструктуру и модули.

Хочется где-то центрально иметь все стили и др. ресурсы, причем так чтоб Visual Studio в дизайнере мог их отображать.

Сейчас все стили находятся на низшем уровне в ResourceDictionary App.xaml, в модулях они исполъзуются как StaticResource, все работает и отображается при старте, но дизайнер VS не находит и не отображает такие ресурсы.

вопрос: Где и что можно/нужно настроить чтоб дизайнер VS корректно отображал стили?

П.С. нашел типовое решение с использованием Prism с теми же тремя уровнями. В VS все отображается как надо (хотя в XAML редакторе студия и ругается на ненайденное имя).
Дополнительный вопрос: это Prism использует какие-то костыли или же можно что-то где-то настроить?

(VisualStudio 2012, Update3)

Answer 1

[Aleksej]

Моя ошибка. На самом деле у меня не три слоя, а четыре - для простоты описания решил упростить и не думал что в этом кроется подвох.
Те модули которые реферренцированы в нижнем слое-оболочке без проблем отображают все стили в дизайнере.
А те модули что подгружаются в модуль-прокладку (и не реферренцированы в оболочке) имеют проблемы в дизайнере.

Решение: в оболочке нужно реферренцировать ВСЕ модули, даже те которые в Unity контейнере будут загружены через другой модуль.

В трехслойной архитектуре этой проблемы не наблюдается, т.к. все верхние слои итак реферренцируются в слое-оболочке.

Альтернативное решение:
1. все ресурсы хранить в верхнем модуле-инфраструктуре
2. в каждом модуле (в т.ч. и в оболочке) прописывать ресурсы инфраструктуры в ResourceDictionary
3. использовать при этом собственную имплементацию ResourceDictionary (как здесь), которая будет в итоге загружать ресурс только если он еще не загружен (т.е. единожды).