Runtime: 调查：原生 AOT

我想不出添加到这个问题的最佳区域标签。 如果您有写权限，请通过添加一个区域标签来帮助我学习。

看起来像一个错字 - * 9. Which of these tasks are apart of your production debugging workflow? (Please select all that apply)也许它应该是“一部分”？

我很高兴看到这个问题！ 😄🚀

问题：对于使用过 .NET Native 工具链的 UWP 开发人员，我们是否应该回答调查只是说我们以前没有使用过 CoreRT，或者由于 .NET Native 与 CoreRT 有很多相似之处（还有一些共享代码？），应该我们只是在注释中提到这一点，然后就我们使用 .NET Native 的经验回答其他 CoreRT 问题？ 🤔

@Sergio0694感谢 UWP 问题。 我同意，如果你使用过开源版本，我认为在注释中提及并回复使用 corert 是有道理的。

感谢您发布此调查！

作为只使用过 .NET Native 的 UWP 开发人员，我也对如何回答某些问题感到困惑。 我对 UWP 的 .NET Native 工具链有很多意见，但我并没有真正看到可以将它们写下来的地方。 如果这超出了本次调查的范围，那完全可以，但可能值得澄清。

我还怀疑“因为 .NET Native 是 UWP 发布版本的默认设置并且在商店中是必需的”可能是人们使用 AOT 的最常见原因，但这不是问题 5 的预填充答案之一。

感谢您在 GUI 选项中包含 Avalonia :) 我们之前已经尝试过 CoreRT+Avalonia，结果是华丽的原生 GUI 应用程序：D 虽然我们已经 2 年没有保持兼容了...

.net 中经常被遗忘的部分是游戏开发，许多平台不允许 JIT 运行，例如控制台或 IOS 设备。
让.net原生AOT成为.net生态的一等公民，对于游戏开发的未来非常重要。
一些游戏引擎推出了自己的 AOT（例如 Unity 使用 il2cpp），但这绝对是一场灾难。
因此，官方解决方案将非常受欢迎。 这可能是一个改变行业的事件。
别忘了游戏行业在利润和营业额上都在赶超电影行业。
控制台是获得主要利润的地方。

用于优化已发布应用程序的现有选项适用于当今 .NET 所针对的大多数场景。

...

AOT 在 GUI 应用程序中很重要。 这就是需要重点关注的地方。 我看不到 webapp、服务等需要它

我不同意。 为了获得最佳的最终用户 UX，游戏引擎、无服务器微服务、桌面 GUI 应用程序、iOS 和Android应用程序、基于WASM的客户端 SPA/库和基本 CLI 工具（约几 MB）需要带静态链接的 AOT。

在过去的几年里，我希望在用 C# 尝试上述所有场景时，我可以轻松地 AOT 编译我的代码，我觉得与 Rust 等基于 LLVM 的语言相比，.NET 严重缺失。

当前发布选项看起来“运行良好”的原因是，.NET 历来不适合上述场景，人们在使用 C# 时只是实现自己的 AOT（例如：Unity、UWP、Mono）。部分 AOT 解决方案如因为本机映像（例如，ReadyToRun）可能在单片服务器应用程序或大型桌面客户端应用程序的冷启动场景中“帮助”，但二进制大小仍然比完整的 AOT 运行时产生的大很多倍。

.NET 对于无服务器/容器化微服务已经不能“很好地工作”——这些可以从 AOT 编译、减少的二进制大小和最小的依赖项中受益匪浅。
当前的 ReadyToRun + 分层编译 + IL Linker 解决方案已经达到了文件大小的限制，这对于自包含部署来说很烦人，例如AWS Lambda 在其博客文章中推荐的那个。

真正的问题是，目前有太多的运行时/代码生成器/工具链/实验有自己的怪癖：IL2CPP/Burst (Unity)、Mono 的 AOT 后端 (Xamarin/Blazor/Uno)、.NET Native/CoreRT (UWP)、 Mono 的 LLVM 后端、CrossGen/ReadyToRun (.NET Core) 等，而 .NET 没有标准化的 AOT 编译工具链是无法接受的。

如果所有这些团队将他们的工程工作结合在 CoreRT、 Mono LLVM 后端或现已废弃的dotnet/lilic等常见的东西上，那么 AOT 对于 .NET 开发人员来说将是一个更好的体验。

现在，大量使用 CI/CD 面向大众的开发人员都可以使用带有静态链接的 AOT，而且这不再只是性能略微提高的烦恼。

C# endgame：本机代码、本机 UI、快速简便的互操作、本机导出和面向性能的 API（例如，System.IO.Pipelines、System.Text.Json）。

我不同意 webapps 不会从中受益的说法。 AOT 对无服务器工作负载（又名 Azure Functions）有很大帮助。 更不用说 CLI 工具的启动时间带来的好处了。

我已经回答了调查，但老实说，自从 .NET Core 1.0 开始以来，我并没有收到这种持续不断的调查询问，也没有明确的方向。

.NET Native 一直是 .NET 应该有的东西，早在 Ext-VOS 项目开始时，你们肯定可以理解 Singularity 和 Midori 的经验，甚至可以获得一些内部服务器。

甚至 Java 也决定弥补其缺少的 AOT 功能，团队并没有询问我们想让它工作的工作负载是什么。

我们几乎不使用 NGEN，因为自从 .NET 发布以来，它的代码质量生成从未得到改进，而且与其他 AOT 编译语言相比，部署工作流程很痛苦。

因此，如果继续前进，AOT 将再次从 .NET 中删除，考虑到托管语言的所有竞争现在都集中在 AOT 工具链上，而且他们也不会询问我们希望使用编译器的工作流程。

我希望看到 .NET 继续蓬勃发展，并成为无论在何种情况下的第一选择，如果有什么可以接管微软仍然迫使我们将 C++ 与 .NET 一起使用的工作流，其他 AOT 编译语言没有问题。

我已经回答了调查，但老实说，自从 .NET Core 1.0 开始以来，我并没有收到这种持续不断的调查询问，也没有明确的方向。

我认为 MS 试图倾听社区的声音，而不是仅仅决定我们想要什么，这是一件很棒的事情。

@jkotas我注意到此调查的两个不同链接正在传播，可以吗？
https://www.surveymonkey.com/r/7THQK5K
https://www.surveymonkey.com/r/SQV8JQK

@texasbruce询问那些回答了关于跨平台 GUI、WCF 和 EF 工具支持的类似调查的开发人员，它有多大帮助。

所以虽然他们问我们很好，但当行动真正发生时会更好。 即使对于跨平台 GUI，MAUI 是否真的会发生还是我们将 Blazor 作为解决方案推到 Web Widgets 中还有待观察。

对我来说，唯一可接受的 AOT 解决方案是它在发布模式下生成一个完全没有 JIT 的真正本机应用程序（没有准备运行的并行解决方案别名），并且它适用于所有¹ .NET 项目开发人员正在工作在。 这特别包括 Winforms 和 WPF。 在最好的情况下，它也应该独立工作，没有任何运行时依赖项，而不会从 3mb 膨胀到 80mb。

¹ 出于技术原因，可能存在 AOT 无法支持的案例/api。 说“全部”意味着不支持所有 API，但 .NET Core 支持的所有项目类型：dll / winforms / wpf / winui / console / maui / ...类似于从 .NET Framework 更改为 .NET Core 的东西，它允许大多数开发人员接管他们现有的应用程序是我的想法。

_我还在 Delphi 中编写了应用程序，我看到我只是编译然后将我的单个 Delphi 可执行文件发送到其他地方并且它只是运行，这让我很烦恼。 而且它更快。 当以特定方式编译时，这同样适用于 C++ 应用程序。 而且您仍然可以调试这两个应用程序，并且当您决定包含 PDB 时，这两个应用程序仍然提供有用的堆栈跟踪/转储。 但是出于安全原因，您也可以决定不包含它，这样也可以正常工作。 我不禁问自己为什么我们不能用 C# 来实现它？ 当我听说 AOT 计划时，我期待这个。_

我总是看到很多提到的反射问题，我相信如果 ASP.net 核心产生一个大的可执行文件，实际上并没有那么重要。

大多数 AOT 是硬性要求的地方是 CLI 工具、游戏和 UI 应用程序，它们可能会挑剔要包含哪些库，并且可以回避一些反射问题。 优先事项应该是启用“全新的”应用程序。

我总是看到很多提到的反射问题，我相信如果 ASP.net 核心产生一个大的可执行文件，实际上并没有那么重要。

随着 Blazor WebAssembly 的发布，我认为可执行文件大小和执行速度将变得非常重要，它可以极大地受益于 AOT。 但无论出于何种原因，调查中甚至都没有特别提到它。

是的，请漂亮！ 我正在考虑使用 Rust 或 CoreRT 以保持内存安全并获得本机速度并让我的代码本机可调用。 但是在 .NET 中拥有 AOT 会很棒，因为它非常丰富和强大，而 Rust 虽然很棒，但并不容易过渡到。

@jkotas我注意到此调查的两个不同链接正在传播，可以吗？

是的，我们对不同的帖子使用不同的 SurveyMonkey 链接。 所有链接都指向同一个调查。 它使我们能够看到响应的分布如何根据人们找到调查的位置而变化。

对于 gamedev 我们需要这个，我暂停了我的游戏引擎https://github.com/amerkoleci/alimer_sharp的工作，转而使用 c++ 支持本机引擎，我也维护 DirectX ans vulkan 的绑定，这里需要性能

对于 gamedev 我们需要这个，我暂停了我的游戏引擎https://github.com/amerkoleci/alimer_sharp的工作，转而使用 c++ 支持本机引擎，我也维护 DirectX ans vulkan 的绑定，这里需要性能

这里的情况相同😄，除了我没有暂停它。 我喜欢 AOT 既是因为更好的启动时间，也是（在我的情况下，更重要的是），有机会拥有更优化的代码 - 我可以将构建时间增加 50% 以实现 10% 的加速，这显然不是t 真的是 JIT 的态度

我对 50% 的构建时间增加 10% 的加速很好，这显然不是 JIT 的态度

这实际上是我希望在 .NET 中使用 AOT 而不是切换到不同的生态系统的重要次要原因之一。 与大型 C++ 或 Rust 项目相比，大型 .NET 项目的快速编译时间让我完全被宠坏了。

我希望 JIT 在开发过程中进行快速迭代，但是一旦我向我的客户交付了一些东西，就需要 AOT。

我曾使用 CoreRT 创建跨平台（和跨平台）本机库。

iOS 和控制台平台中禁用 jit 的游戏引擎迫切需要带静态链接的 AOT，并且还需要多种 aot 编译模式：

1. 完整的aot
2. 支持 jit + aot 或解释器 + aot 运行模式的混合 aot
   混合aot对游戏行业非常重要，它可以改变游戏规则

iOS 和控制台平台中禁用 jit 的游戏引擎迫切需要带静态链接的 AOT，并且还需要多种 aot 编译模式：

1. 完整的aot
2. 支持 jit + aot 或解释器 + aot 运行模式的混合 aot
   混合aot对游戏行业非常重要，它可以改变游戏规则

像iOS平台上的mono，aot+interpreter运行模式。

完整的 Aot、单个 exe、独立的运行时和剪裁不必要的代码，这绝对让我很生气 XD

这个问题我已经等了10年了。 该死的，我有 5 个很酷的项目正在硬盘上积灰，因为如果我发布它们，任何孩子都可以反转它们，对 GUI 进行一些小改动并作为自己的出售。

我在 PC 平台上使用 Unity 开发了 Robocraft、Cardlife 和 Gamecraft，并且从不需要使用 IL2CPP，除非需要（请阅读 Xbox one），甚至对于游戏服务器也不需要。 当需要性能时，我个人认为 JIT 编译和 Burst 之类的解决方案（它比我使用显式内在函数做得更好）的组合已经足够了。 但是，我知道对于需要完全本机代码的平台和那些硬件资源非常宝贵的平台，AOT 是必要的。 我了解 .net 平台开发人员对 AOT 的看法是多么复杂，但如果我们希望它在游戏开发中得到更广泛的采用，我认为这不是一个选择。 老实说，Unity 垄断了 IL2CPP 和 Burst 等技术，这让我有点害怕。

我们开发高性能、高可扩展性的金融/科学模拟器。 根据用户创建的模型的复杂性，我们的模拟可以运行几分钟到几天不等。

由于我们模拟软件的性质，启动时间和软件/二进制文件大小几乎都不是问题。 就此而言，安装产品所需的时间也不是问题。 例如，如果编译是安装的一部分，我们完全可以接受，即使这样的过程需要很长时间。

我会说运行期间大约 25% 的代码是动态创建的，因此首选混合方法； AOT 和 JIT 编译的某种组合。 如果必须解释动态位，我认为 AOT 的许多好处都会减少，至少在我们的用例中是这样。

GC 是我们的头号问题，使我们无法实现更高的可扩展性（例如，一旦我们获得大约 44 个核心）。 让编译器能够进行更深入的程序集间优化、积极的内联和转义分析，可以允许在堆栈而不是堆上分配更多的短期对象。

在我们的代码库中有很多地方 JIT 代码质量成为瓶颈，特别是在寄存器分配和处理许多结构时。 这迫使我们编写代码来操纵 JIT 编译器以做正确的事情（一场脆弱、令人困惑且难以维护的拔河比赛）或放弃使用本机代码（并且我们因缺乏内联而失去了很多好处和来自 GC/PInvoke 转换的开销）。

有时，对代码质量的微小改进可以在跨多个内核运行数小时的模型过程中获得疯狂的胜利。 对我们来说，JIT 在性能方面变得有点脆弱（甚至更不确定），因为我们的代码库随着开发而变化。 我们希望 AOT 编译器可以花费更多时间来编译和生成更高质量的代码，减少一些不必要的性能波动，并允许我们将更多的代码库保留在 C# 中。

总的来说，我希望看到更多投资于 JIT 和 AOT 技术。

抄送@AndyAyersMS

iOS 和控制台平台中禁用 jit 的游戏引擎迫切需要带静态链接的 AOT，

我完全同意这里。 由于我们需要解决这个问题（在非 Unity 项目的游戏控制台上运行的 C# 代码），我们正在使用基于 Mono-AOT 的工具链。 但它有一些严重的局限性，表现不佳。

因此，我们正在考虑让 CoreRT 在 3 个 poplar 游戏机（XBox One；PlayStation 4 和 Nintendo Switch）上运行。 最初的概念证明表明它确实有效（仍然有一些限制），但与基于 Mono 的解决方案相比，它已经有了显着的运行时性能改进。

但是随着游戏机官方支持这种使用原因的 NDA 情况，这比首先获得官方原生 AOT 更加牵强。

对我们来说，JIT 在性能方面变得有点脆弱（甚至更不确定），因为我们的代码库随着开发而变化。

@jpapp05我很想听听更多关于您的应用程序的信息，特别是上述问题，因为这是我的主要关注点之一。 如果有帮助，请随时离线联系我（通过个人资料中的电子邮件）。

嗨@AndyAyersMS ，那太好了。 我会离线与您联系，因为我可以更自由地交谈，但我很乐意发回我们讨论的任何摘要，以造福他人。

不知道这是否是一个问题，但只是在这里提一下。
对我们来说，一个重要的特性是能够在运行时动态加载和卸载本机程序集。

@movedoa查看NativeLibrary API https://docs.microsoft.com/en-us/dotnet/api/system.runtime.interopservices.nativelibrary?view=netcore-3.1

我最大的问题是，通常 .NET 可以很容易地反编译，除了 UWP Native，至少就我测试而言（我希望是对的）。 不是以“正常”的公司心态，有人会在一个可以轻松反编译的项目中放置大量 IP。
Linux 很酷，但所有桌面应用程序都适用于企业界的 Windows。

也许为了让生活更轻松，请放置一个复选框，上面写着：
本机编译（仅适用于 WINDOWS 10 桌面版！）
伙计，这样做，我不再关心 AOT。 如果它适用于 ASP.NET Core，那就太棒了！ 如果不是，我真的不在乎。

顺便说一句，感谢您提出问题并进行调查，您做得很好，因为您正在向在工作中使用该技术的人征求意见。 我认为（事实上我很确定）你仍然会错过很多桌面开发人员的意见，他们通常不会参与 Github 上的这些事情。 不是每个人都记得（或知道）.NET 代码很容易被反编译，我相信如果他们的老板知道的话，他们会发疯的：咧嘴笑：。

不是每个人都记得（或知道）.NET 代码可以很容易地被反编译

嘘......当我试图弄清楚 Unity 或 3rd 方包中的幕后工作原理时，Rider 自动为您执行此操作的事实令人惊叹。 不过，现在已经不那么重要了，因为很多代码一开始都是开源的，但你明白我的意思。

@jcbeppler您错了，这是对字节码与本机的常见误解，这只是拥有正确工具的问题。

https://www.hex-rays.com/products/decompiler/compare/compare_vs_disassembly/

Hex-Rays 只是一种可能的解决方案，还有其他可供选择。

@MostHated是的，我明白了。 事实上，在 .NET 中反编译软件非常简单，它就像是开源的，许多公司不希望他们的软件是开源的。 “天下没有免费的午餐”😄

@pjmlp我知道反编译与反汇编之间的区别。 我对反汇编我的软件无能为力，但本机编译可以使软件更加安全，因为这个人无法进行非常简单的反编译。 反汇编的软件肯定会看起来很奇怪，反汇编的代码甚至可能无法正常运行。

@jcbeppler您错了，这是对字节码与本机的常见误解，这只是拥有正确工具的问题。

目前，反编译的 .NET 程序会显示完整的源代码。 这甚至包括所有方法名称和变量名称。 这对于调试来说很酷，并且允许我们在发生异常时拥有“可读”的堆栈跟踪。 然而，它是一个巨大的安全漏洞，也是 .NET 混淆器市场巨大的原因。

可以反汇编本机应用程序。 但它并没有透露其完整的 C++/Delphi 等源代码（有一些工具试图重建此源代码，但结果很糟糕）。 你得到的最多是汇编代码和控制流程图。 如果你很幸运并且它附带了符号文件，你也可以获得函数名称，但在发布模式下，这个符号文件通常不包括在内，再​​次出于安全目的。

我们可能会沉浸在谈论本机代码如何成为真正保护的细节中。 在我看来，它不是破解方面的保护（尽管由于完整的方法/变量名称和完整的 C# 源代码生成，可以在不需要任何特殊知识的情况下删除许可证检查）或调试，而是防止窃取者。 像 dnSpy 这样的工具甚至可以通过单击将 .NET 应用程序导出到完整的 VS 项目中。 没有这样的工具可以以相同的方式处理本机代码。 因此，对于商业应用程序来说，生成本机代码将是一个巨大的胜利，此外，他们不再需要每年为仅重命名最终应用程序中的所有方法和变量的东西支付数千美元。

我很好奇这次调查的结果。 是否有计划公开人们的投票方式？

@Symbai这不是针对任何事情的保护，因为任何试图使用 NDK 作为保护其 IP 的手段的 Android 开发人员都会告诉你。 您简要提到的应用程序只需单击即可执行相同操作，即使它们通常将 C 或 C++ 代码假定为原始源代码，它们也足以窃取您的算法。

我想要 AOT，对于 .NET 将长期失去对 Rust、Go、Swift、C++、Java (GraalVM)、桌面、控制台和移动/物联网应用程序的启动时间非常重要的场景，内存使用有很高的限制并且由于装配负载上的 JIT 导致的速度损失是不能容忍的，就像在某些 ASP.NET 场景中，当一个人扩展其 100 个 K8S pod 实例时，AOT 代码可能是相关的。

另一方面，我也发现在 JIT 是可行的情况下，保持 JIT 能力并改进它们是相关的。

有很多语言提供两种编译模型，让用户根据情况进行选择，所以基本上让 JIT 保留，并将 AOT 故事改进为 .NET Native 方向，同时忘记名为 NGEN 的胆小尝试。

@Symbai这不是针对任何事情的保护，因为任何试图使用 NDK 作为保护其 IP 的手段的 Android 开发人员都会告诉你。 您简要提到的应用程序只需单击即可执行相同操作，即使它们通常将 C 或 C++ 代码假定为原始源代码，它们也足以窃取您的算法。

窃取我可以接受的算法，但不是 .NET 今天允许的（例如 WPF），一个人可以将您的完整应用程序精美且轻松地准备好作为 VS 项目运行。 我认为带有 Native 编译的 UWP 做得很好，如果有人想反汇编它，好的，祝你好运！ 无论如何，我将始终使用 Native 编译。 我无法谈论的 Android 世界，曾经用 Xamarin Forms 尝试过 AOT，但它确实没有像我预期的那样工作。

我认为带有 Native 编译的 UWP 做得很好，如果有人想反汇编它，好的，祝你好运！ 无论如何，我将始终使用 Native 编译。 我无法谈论的 Android 世界，曾经用 Xamarin Forms 尝试过 AOT，但它确实没有像我预期的那样工作。

剧透 - 试图了解您的来源的人可能正在尝试改进/扩展/与您整合，而不是扯掉您。 如果他们试图敲诈你，那么你的指标真的很愚蠢。

如果我写一本书，然后在我出版之前让别人把它翻译成日语——我可能会认为我真的很聪明，因为我不懂日语，我的任何一个朋友也不懂。 但现实是，整个国家都可以读那本书——如果我假装不这样，我只不过是在自欺欺人。

作为一个没有反汇编原生二进制文件经验的开发人员，我这样说，并决定对星际公民的加密和数据格式进行逆向工程。

我，一个零经验的人，花了两周时间从一无所有，到拥有一个不仅可以解密其加密数据文件，还可以将其专有数据格式转换为 XML/JSON 的程序。

在那两周之后——我可能没有准备好你的完整应用程序作为 VS 项目运行——但我也意识到我不需要。 将我自己的代码注入现有应用程序要简单得多，而不必处理他们的所有代码。

拥有一个不仅可以解密其加密数据文件的程序

加密是完全不同的东西。 反编译视频游戏以创建模组是完全不同的事情。 大多数游戏开发者并不介意他们的粉丝是否创建了模组，而是展示了他们对游戏的热情和热爱。 也许“加密”根本不是加密，而是文件只是打包成更小的尺寸？ 因为不必在磁盘上存储数千个单个文件。 性能也可能是一个原因......从磁盘读取许多小文件比读取一个大文件要慢。 2 周后，您可以解压缩打包的图像。 您可以更改某些数据文件中的文本。 这很好，但不是像我这样的人想要摆脱 JIT 的原因。

我们现在遇到的问题是 JIT 代码可以完全反编译成完整的源代码，Java 和任何其他 JIT 语言都有同样的问题。 本地代码可以反汇编（这会将机器代码变成汇编代码），本地应用程序可以有足够的能力进行破解，这一切都是真的，但本地代码无法编译成完整的源代码。 你见过像 dnSpy 这样的 C++ 代码工具吗？ 德尔福代码？ 我没有。 这是因为无法获得变量和方法名称，因此正确编译后它们不再存在。 不可能将反汇编转换为 C++ 并生成一个可以编译的完全工作的项目。 这听起来对您来说不是那么重要，但对于商业应用程序来说却是一件大事。 我们只是想摆脱这样一个事实，即 .NET 应用程序是一本开放的书，每个知识绝对零知识的人都可以阅读。 当我们投入数千美元进行研究时，我们不希望每个人都看到它并在几秒钟内复制它。 我们希望摆脱为混淆器支付数千美元的麻烦，该混淆器的唯一目的是重命名所有变量和方法名称，这样人们就不能再打开应用程序并搜索“许可证”来立即获得它。 它不仅（但主要是）混淆器的成本，而且混淆器会产生额外的问题。 我自己经常遇到这个问题，尤其是在 .NET Core 发布的频率上。 我们不得不等待几个星期才能获得使混淆器与最新的 .NET Core 版本一起工作的补丁。

当您作为开发人员面临所有这些问题时，您还必须向您的业务经理解释这些问题。 在某些时候，他可能会问你，选择一种不同的编程语言是否更好。

使用 C++ 和 Delphi，您根本就没有这个问题。 我知道这对每个人来说都不是问题。 开源开发人员会发现 JIT 更加有趣和有用。 很难向他们解释为什么有人希望他的源代码是一本封闭的书，而他们认为开放的书更好。 所以理想情况下，我们不必相互解释我们完全不同的观点，AOT 将只是一个开关，如果你愿意，你可以在发布模式下打开它。 如果您不想要，请继续使用 JIT。

我真的很感谢 .NET 团队让我们选择“保护”作为我们想要 AOT 的原因❤。 这表明他们了解某些人的需求。 如果民意调查显示有人投票支持它，我们可能最终有机会 AOT 实现会像 C++ 编译器一样处理这个问题。 仅供参考：我把它放在引号中是为了避免进一步讨论 AOT 实际上有多少保护，关于这一点的观点非常广泛，正如我们可能已经注意到的那样。

安全不是全部或全部。 删除 IL 并不能阻止坚定的攻击者逆向应用程序。 但它创造了在实际意义上相关的障碍。 这是纵深防御。 这就是为什么 IL 混淆产品可以合理使用的原因。

我的一个朋友通过将 IL 反编译为 C# 并进行了一些微不足道的修改，破解了 .NET 产品。 他无法破解原生应用程序。 这要困难得多。 他还不得不在 IL 混淆器存在的情况下放弃，因为反编译器工具在这些二进制文件上崩溃了。 同样，这些产品在实际意义上受到保护。 有效。

@Symbai

Have you ever seen a tool like dnSpy for C++ code? Delphi code?

Hex-Rays 对 C 语言做得很好，它有宏来帮助决策过程。

拥有 C 源代码，将其转换为 C++ 或 Delphi 是孩子们的游戏。

另外，现在我们有了人工智能来帮助那些不够熟练的人。

剥离二进制文件的神经逆向工程

Hex-Rays 对 C 语言做得很好，它有宏来帮助决策过程。

您是为 Hex-Rays 工作还是为销售混淆软件的公司工作？ 看起来。

无论如何，即使你把它转换成C，代码也将离一个好的C#架构相去甚远。 即使你得到了一些代码，你也必须付出大量的努力来改变、改进等等......
如果对您而言，本机编译无关紧要，好的。 但对很多人来说，这很重要。

BTW：你看起来对保持 JIT 编译很感兴趣，而且你似乎在反汇编软件方面有很多经验。 我想知道为什么以及在哪里使用它？！

不管你们中的任何人如何看待 IL 与机器代码的反编译的易用性，它都不会改变这样一个事实，即它是真实企业的真正需求。 （在奶牛回家之前，我们可以争论该要求的有效性或无效性。）

出于这个原因，我以前的雇主明确禁止向外部发送 .NET 或 JVM 工具。 就在我离开之前，一个团队说服上级让他们发布一个应用了严重混淆的工具，但除此之外，我们正在用 C++ 编写外部工具以满足公司政策。

这个讨论已经偏离了轨道。 如果你们都想就 AOT 是否与 IP 保护相关进行一场激烈的争论，请在其他地方进行。

Hex-Rays 对 C 语言做得很好，它有宏来帮助决策过程。

您是为 Hex-Rays 工作还是为销售混淆软件的公司工作？ 看起来。

无论如何，即使你把它转换成C，代码也将离一个好的C#架构相去甚远。 即使你得到了一些代码，你也必须付出大量的努力来改变、改进等等......
如果对您而言，本机编译无关紧要，好的。 但对很多人来说，这很重要。

BTW：你看起来对保持 JIT 编译很感兴趣，而且你似乎在反汇编软件方面有很多经验。 我想知道为什么以及在哪里使用它？！

相反，我拥有将原生代码逆向工程为第三方可以进一步使用的源代码的技能，所以我充分意识到编译为原生代码只是脚本小子的一个障碍，这似乎是缺失的理解这里。

编辑：也停止我的评论。 只是想回复一下人身攻击。

Cloud Native 和 WPF 必须是 AOT。
Windows 客户端没有运行时！ 无 JIT

调查结果已发布 - https://github.com/dotnet/runtime/issues/41522。 我们现在正在跟进提供联系信息并有一些其他后续问题的人。

iOS 和控制台平台中禁用 jit 的游戏引擎迫切需要带静态链接的 AOT，

我完全同意这里。 由于我们需要解决这个问题（在非 Unity 项目的游戏控制台上运行的 C# 代码），我们正在使用基于 Mono-AOT 的工具链。 但它有一些严重的局限性，表现不佳。

因此，我们正在考虑让 CoreRT 在 3 个 poplar 游戏机（XBox One；PlayStation 4 和 Nintendo Switch）上运行。 最初的概念证明表明它确实有效（仍然有一些限制），但与基于 Mono 的解决方案相比，它已经有了显着的运行时性能改进。

但是随着游戏机官方支持这种使用原因的 NDA 情况，这比首先获得官方原生 AOT 更加牵强。

@RalfKornmannEnvision您是否使用带有 LLVM 代码生成的 Xamarin Xbox One/PS4 Mono 端口？

@RalfKornmannEnvision您是否使用带有 LLVM 代码生成的 Xamarin Xbox One/PS4 Mono 端口？

@lateralusX由于集成是由其他人完成的，我不知道任何细节。 但据我所知，他们使用了为 Xbox One/PS4 提供的单声道端口，并为 Switch 制作了一个简单的端口。 他们自己。

@RalfKornmannEnvision很高兴联系并讨论与此相关的经验。 LLVM 代码生成（取决于项目）对生成的代码有非常积极的性能影响，所以如果没有使用（需要启用），通常只需启用它就可以获得很多。 你在 DotNetEvolution discord 服务器上吗，如果是这样，也许我们可以在那里进行与此相关的离线讨论？

@lateralusX我很确定从事此工作的团队成员已经启用了 LLVM 代码生成并尝试了其他事情。 他们在进行另一个项目之前的最后声明是，这是他们能做的最好的事情。

作为我调查的一部分，我使用 Xamarin Android 构建了一个包含核心组件的基准测试，并在基于 Tegra X1 的设备上运行它，看看我们是否因为我们的 Mono 的自定义 Switch 端口的问题而失去了性能。 不幸的是，Xamarin 项目的性能与我们在 Switch 上看到的并没有什么不同。

很抱歉，我不在这个不和谐的服务器上，老实说，我对当前的 MONO 集成了解不多。 从我的角度来看，这个项目无论如何都是一条死胡同。 当前的 CoreRT 原型（虽然官方支持更少）在性能和可用性方面已经非常出色。

@RalfKornmannEnvision好的，感谢您的信息和反馈，都非常有价值。