WPF 应用程序可以编译为本机代码吗？答案

【问题标题】：Can WPF apps be compiled to native code?WPF 应用程序可以编译为本机代码吗？
【发布时间】：2011-01-16 09:35:59
【问题描述】：

我知道有像 Salamander 这样的工具可以将 .NET WinForms 应用程序编译为完全本地代码，而无需在机器上安装 CLR/.NET Framework。 WPF 应用程序也可以这样做吗？

【问题讨论】：

Salamander...适用于所有未安装 .NET 框架的 Windows 机器（Win98/2k？）
那么 Salamander 与 WPF 以及 WinForms 一起工作？这是我的问题。
您可以指定您的应用需要 WPF - 我确信 WPF 的工作速度比试图猜测它正在制作的 direct-x 调用要快得多
@Chris S：即使它被编译为本机，它仍然无法在 98/2k 上运行，因为这些操作系统不支持许多 API 要求......
更正：根据 Salamander 的网站，Salamander 编译的代码确实需要在目标机器上安装 CLR/.NET Framework。 Salamander 所做的只是将标准 IL 更改为 Salamander 自己专有的“本机代码”格式，因此如果没有特定于 Salamander 的反编译工具，就无法对其进行反编译。代码仍然在 CLR 上运行并使用常规的 NET Framework 库。

【解决方案1】：

根据this page，Salamander 支持 .NET Framework 3.5，这表明支持 WPF。

话虽如此，我还没有看到像这样支持 WPF 的工具很好。 WPF 中有很多是通过运行时对象元数据处理的。

此外，试图避免安装 CLR 通常会导致比它解决的问题更多的问题。必须安装 CLR 应该不是问题，尤其是现在，对于任何合理的应用程序。

【讨论】：

嗯，我也关心逆向工程，这对于 MSIL 与本机代码来说非常容易。
@Rhubarb：在这种情况下，我会使用混淆器，而不是尝试使用本机代码。元数据使逆向工程更容易 - 并且有非常好的本机代码反编译器。一个好的混淆器可以提高标准，我个人不会担心它，并且不会“破坏” WPF...
Hex-Ray 的 IDA-Pro 适用于大多数情况：hex-rays.com/idapro 如果您搜索的话，还有其他一些...这一切都是为了提高标准，因为没有什么是不可能的...... .
似乎原生 + 混淆会胜过 MSIL + 混淆，我错了吗？
视情况而定。 Native + Obfuscation 可能更难反编译......但是，它的开发速度也较慢。但是，.NET 的大部分功能和灵活性都来自于元数据的可用——因此放弃它（如果你使用本机，就会发生这种情况）有一些显着的缺点。具体来说，期望它完全破坏 WPF - 因为 WPF 在任何地方都使用 TypeDescriptors...

【解决方案2】：

您还可以采用 Viewmodel 方法，将 WPF 逻辑全部映射到本机业务逻辑，并使用 C++/CLI 进行命令和属性绑定，正如我在 presentation last year 中所述。

【讨论】：