管理WPF资源(画笔等)

Question

通常情况下,我会在'distrib'程序集中放置我认为的宪法根资源,例如品牌颜色/画笔,字体和大小.

Distrib程序集旨在指向第三方开发商店,因此他们可以访问我们的合同,界面和品牌风格.

然后建立更复杂的资源,并在它们被使用的地方宣布"更近".

我来到了一个有机,错误,随意增长的应用程序.奇怪的是,模块使用主应用程序可执行项目中的资源,即使模块没有引用应用程序.

我假设因为他们将所有资源"导入"到App.xaml中,所以它们可用于伪造的运行时设计器上下文.

我的问题是

如果这就是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只调用ResourceDictionary中的原始MS实现,并且静态注册包URI方案也无济于事!! 哎呀.

所以我需要破解,第二个选项是将所有内容粉碎到App.xaml中并避免合并的字典.

这意味着更少的控件/视图,并在我的可分发库中设置一个设计时字典,我猜他们无法访问app.xaml的工作.

我认为这是有道理的.

有趣？告诉微软

它可能适用于Silverlight,但我希望WPF人员可能正在倾听,或者至少它可能会修复一个平台 - 我已经向UserVoice网站添加了一个"想法",您可以投票.

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

Answer 1

是的，App.xaml 的事情似乎是它“应该”工作的方式，尽管显然正如您所发现的那样，其他方式也是可能的。不过，性能问题令人恼火，而且 App.xaml 方式也令人恼火，因为它们在设计时无法解决（至少，它们对我们来说不是，如果它们对您来说是这样，我想知道为什么）。

然而，将它们放入 App.xaml 是我发现的唯一接近“官方”声明的技术。