【问题标题】:Why do I need a 'dummy' line of code in order for PresentationFramework to load?为什么我需要一个“虚拟”代码行才能加载 PresentationFramework?
【发布时间】:2020-02-11 15:48:02
【问题描述】:

我有一个非托管应用程序,它的某些用户界面使用 WPF 程序集。

最初我遇到了以下异常:

System.IO.FileNotFoundException 未处理消息:无法加载 文件或程序集 'PresentationFramework ...

(与Changed framework version results in: Could not load file or assembly PresentationFramework?的原因不同)。

PresentationFramework 是我的程序集的引用。

我已通过添加一行 C# 代码来解决此问题,该代码似乎强制或欺骗编译器/运行时加载 DLL:

// Refers to an arbitrary enum in PresentationFramework.Classic.dll
var dummy = Microsoft.Windows.Themes.ClassicBorderStyle.None;

然后我在运行时没有异常。

否则,对该 DLL 中任何内容的唯一引用是在 XAML 中。具体来说:

<ResourceDictionary Source="pack://application:,,,/PresentationFramework.Classic;component/themes/Classic.xaml"/>

但显然这个 XAML 引用不足以让 DLL 在运行时正确加载。


这个“虚拟”解决方案是可以的,因为它确实有效,但我不明白为什么这是必要的,这让我觉得我错过了更重要的事情。

这是一个正确的解决方法吗?首先这是必要的原因是什么?

【问题讨论】:

    标签: c# wpf xaml


    【解决方案1】:

    XAML 和 C# 是两种不同的语言,具有独立的解析器和编译器。事实上,对 XAML 运行时错误的早期调试器支持大约是“不存在”。如果您遇到 XAML 编译器错误? C# 编译器只会使用最后一个有效的 XAML 编译。

    虽然您可能永远不会使用它,但完全可以在运行时动态加载 XAML 设计:https://blogs.msmvps.com/bsonnino/2016/07/21/loading-xaml-dynamically-part-1-loading-views-dynamically/

    此时编译器在编译时不能依赖 XAML 中写入的内容。

    XAML 中的命名空间?它们只是关于将 .NET 类纳入 XAML 解析器的范围。它们对于代码的 C# 部分并没有那么重要。

    【讨论】:

      猜你喜欢
      • 2011-03-01
      • 1970-01-01
      • 1970-01-01
      • 2021-04-28
      • 1970-01-01
      • 1970-01-01
      • 2020-12-22
      • 2018-04-20
      • 1970-01-01
      相关资源
      最近更新 更多