wpf - 管理 WPF 资源(画笔等)

Question

通常，我将我认为的宪法根资源(例如品牌颜色/画笔、字体和大小)放在“分发”程序集中。

Distrib 组件|ies 设计用于提供给第 3 方开发商店，因此他们可以访问我们的契约(Contract)、界面和品牌风格。

然后建立更复杂的资源，并在使用它们的位置“更近”地声明。

我遇到了一个有机地、错误地、随意地增长的应用程序。奇怪的是，这些模块使用来自主应用程序可执行项目的资源，即使这些模块没有引用该应用程序。

我假设因为他们将所有资源“导入”到 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 中并避免合并字典。

这意味着更少的控件/ View ，并在我的可分发库中设置设计时字典，我猜这可以完成他们无法访问的 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 是我发现的任何接近“官方”声明的唯一技术。