【问题标题】:How Cross-Platform or Platform-independent is achieved in .NET Core?在 .NET Core 中如何实现跨平台或平台无关?
【发布时间】:2021-03-15 04:09:20
【问题描述】:

我们都知道 .NET Core 是独立于平台的,可以在 Windows、Linux 或 Mac 等任何操作系统上运行。

我只是有点想了解,在 .NET Core 的情况下如何实现跨平台,而在 .NET Framework 的情况下则不可用。

如果有人解释一下会很有帮助。

提前致谢

【问题讨论】:

    标签: asp.net-core .net-core cross-platform asp.net-core-3.1 platform-independent


    【解决方案1】:

    有多种因素促成了这一点。重要的包括:

    • 与操作系统特定的 API 集成

    操作系统提供了许多低级功能,从网络文件访问到调度。就像在 C/C++ 中一样,您可能需要为 Windows 实现不同于 Linux 或 macOS 的东西。

    .NET Framework 是特定于 Windows 的,因此必须针对 Linux / macOS 以不同的方式抽象和实现许多东西以实现兼容性。例如。使用 unix 套接字 API 代替 Winsock 进行网络。

    另请注意,垃圾收集利用了内存和调度 API 的更高级用途,这些 API 在所有平台上也不存在 1:1,因此存在实施差异。

    • 重新实现一些为 .NET 包装的 Windows 功能

    图形 (System.Drawing) 或 WCF 托管等某些功能实际上更多是 Windows 的功能,而不是 .NET Framework 的功能。其中一些必须在纯 .NET 中重新实现,或者分离成可以在 .NET Core / .NET 5+ 上使用但仅在 Windows 上运行时才能使用的支持包。其他(WCF 托管)已完全删除。

    另一个很好的例子是全球化支持,因此在 .NET 中处理特定于语言的细节。这用于许多字符串操作、字符串格式化(例如,用各种语言格式化月份名称)等等。在 Windows 上,这曾经使用 National Language Support API,但对于 Linux 和 macOS,这是使用 International Components for Unicode (ICU) 库为 .NET Core 实现的。这会导致这些版本之间存在一些行为差异。在 .NET 5+ 中,即使是 .NET 的 Windows 版本也将尝试使用 ICU,因为它已包含在 2019 年的 Windows 10 中。

    • 为不同架构生成原生代码

    .NET 使用用户代码编译成的中间语言 (IL),它不是机器可执行格式,但可以翻译成针对运行代码的系统的本机机器代码进行优化。这种即时编译器 (JIT) 需要支持所有机器架构(英特尔架构、ARM 架构、32/64 位,现在 WebAssembly 也即将推出......)。 .NET Framework 中的 JIT 编译器仅支持 Intel 指令集。

    有些架构/操作系统甚至对此有详细说明。例如。 macOS 64 位 ARM(例如 M1 芯片)在调用约定(需要与操作系统和库集成)方面与 Linux 略有不同。此外,运行 JIT 编译代码的安全系统也需要一些更改(写异或执行内存页)。

    【讨论】:

    • 感谢@Martin 的解释!!从最后一点 - Generating native code for different architectures 这意味着在特定平台上可以使用不同的 RyuJIT 实现以供 .net 应用程序工作,对吧?
    • 是的,这就是重点,为例如生成机器代码。 x86、x64、ARM64 和可能的差异(如前所述,例如 macOS ARM64 中存在细微但重要的 ABI 差异)
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2013-06-23
    • 1970-01-01
    • 2018-06-24
    • 1970-01-01
    • 2016-11-05
    相关资源
    最近更新 更多