.NET 平台标准中有哪些平台？答案

【问题标题】：What are the platforms in the .NET Platform Standard?.NET 平台标准中有哪些平台？
【发布时间】：2016-05-27 02:31:16
【问题描述】：

目前正在尝试了解 .NET 平台标准，我发现自己对“不同平台”的概念感到非常困惑。

我会尽量说明我的观点。我现在对 .NET 框架的看法是，.NET 大致由 CLR、BCL 和用于启动 CLR 并提供虚拟机和底层操作系统之间的接口的支持软件组成。

因此，当我们使用 .NET Framework 进行编码时，我们确实以某个版本的框架为目标，因为我们从 BCL 使用的类型随框架一起提供，因此取决于特定的版本。

现在，.NET Core 与我理解的完全不同。并非所有都像那样打包在一起。我们有 CoreCLR，它是一个运行 IL 的轻量级 VM，CoreFX 是正确组织为 NuGet 包的库，到目前为止，我们有 DNX/DNVM/DNU，它提供了诸如启动 CoreCLR 和与操作系统。

无论如何，尽管我们在 Windows 7、Windows 8 或 Windows 10 上安装框架，我们针对框架进行编码。

现在，在 .NET 平台标准规范中，我们看到以下定义：

平台 - 例如.NET Framework 4.5、.NET Framework 4.6、Windows Phone 8.1、MonoTouch、UWP 等。

之后我们还会看到一个平台列表，其中包括

.NET Framework 2.0 - 4.6
Windows 8
Windows Phone 8.1
银光 4、5
.NET Framework 4.5.1 - 4.6 上的 DNX
.NET Core 5.0 上的 DNX

现在这完全让我感到困惑。不过，我总是：我们针对 .NET Framework 进行编码，无论如何，框架就是框架。

但这里我们有这些平台，其中包括 .NET 框架只是众多平台之一。例如，我们有 Windows 8，但是等一下，在 Windows 8 上运行 .NET 与在任何其他操作系统上运行 .NET 不一样吗？为什么它与 .NET Framework 2.0 - 4.6 平台分开？

我们还将 DNX 作为特定平台。这让我想知道：平台是与引导虚拟机和提供与操作系统接口相关的“支持东西”吗？还是平台包含虚拟机？

无论如何，可以看出我很困惑。这些平台到底是什么，这与我目前对 .NET Framework 的理解有何关系？另外，为什么要单独描述 .NET Framework 2.0 - 4.6？此处描述的所有内容不是 .NET Core 的某个版本吗？

【问题讨论】：

.NET 中没有“虚拟机”。
@IInspectable blogs.msdn.com/b/brada/archive/2005/01/12/351958.aspx “所以底线是 CLR 和 JVM 在同一个类中，您是否称该类软件为“虚拟机”“执行引擎”取决于您的观点。”
我一直认为 CLR 是一种虚拟机。一种软件，充当应用程序在其上运行的沙箱。我们将 IL 字节码提供给该 VM，并且包含的 JIT 编译器生成本机代码并在该特殊沙箱上运行它。尽管我从未详细研究过 CLR，但 GitHub 上的文档将其描述为“一个完整的高级虚拟机，旨在支持多种编程语言和它们之间的互操作”。这让我相信我的粗略理解是合理的。
本文档中的“.NET Framework”是指您通过 msi 安装程序在机器范围内安装的非核心、非开源、.net。它包括 gac (c:\windows\assembly) 和编译器等 (c:\windows\mictosoft.net\framework64\vX.X)
是的@RichardSzalay，我猜到了版本。文档将其称为 .NET Framework 2.0 - 4.6。但是，文档仍然认为它是一个不同于 Windows 8 的平台。但是要在 Windows 8 或任何操作系统上运行 .NET 应用程序，我们需要安装相应的 .NET Framework，对吗？因此，最终我们将在 .NET Framework 本身之上运行。我确实了解拆分 .NET Full 和 .NET Core，但我不明白所有这些平台的想法。

标签： c# .net windows dnx .net-core

【解决方案1】：

我们针对框架编写代码。

嗯，你确定。当您在代码中操作字符串时，您将始终使用 System.String。而且它（几乎）总是以完全相同的方式使用完全相同的方法和属性。

但是显示字符串确实有你不能真正忽略的实现细节：

如果您想在 Linux 或 OSX 上的 Unix 终端中显示它，那么您需要以 Mono 或 CoreCLR 为目标，这些框架实现可以在此类操作系统上运行。
如果您想在 Windows 应用商店应用程序（又名 WinRT、又名 Windows 8、又名 UWP）中显示它，那么它实际上是一个隐藏在引擎盖下的 HSTRING，这是一个非常隐蔽的细节，您不必担心。但确实需要一个 UI 小工具，例如 Windows.UI.Xaml.Controls.TextBlock，这是一个高度特定于 WinRT 的类
如果您想在浏览器中显示它，那么您需要以 ASP.NET 或 Silverlight 为目标，这些框架主机经过优化可在 Web 服务器上运行或作为浏览器的插件运行。
如果您想在由小型锂离子电池供电的设备（如手机）上展示它，那么您将不可避免地需要处理经过优化以尽可能少用电量的框架版本。这确实会影响您必须编写的代码，燃烧 100 瓦的代码和保持小电池工作 8 小时的代码之间存在巨大差异。除了需要大量使用 async/await 之外，您无法直接看到任何东西，但肯定会严重影响运行时。需要以 Xamarin 或 WinRT 为目标。
如果您想在任何操作系统上显示它，那么您确实需要针对不使用 .NET 在 Windows 上使用的那种技巧的框架版本来让 EXE 启动 CLR虚拟机。这需要 dnx.exe，就像您对用 Java 或 Python 编写的程序使用 java.exe 或 python.exe 一样。

如果这些实现细节无关紧要，那就太好了。但它在实践中的工作方式并非如此，随着 .NET 的激增并在越来越多的设备和操作系统上可用，它也不可避免地变得更加复杂。尽早选择您的预期目标，这很重要。

【讨论】：

感谢@HansPassant 的回答。那么这些平台是出现在介绍 .NET Core 的文档中的垂直领域吗？每个平台都由一个运行时环境（CLR、Mono、CoreCLR）和一组基本库（如 BCL）以及用于启动运行时环境和与操作系统接口的支持软件组成？在这种情况下，因为 .NET Framework 2.0 - 4.6 拥有所有这些，所以它是一个特定的平台。但是，例如，为了开发商店应用程序，使用一组新的库和新的支持内容构建了一个新的运行时，并且所有这些垂直领域都是如此？
我故意避免发布该图表，它并没有真正帮助 imo。底层最重要，.NET 必须在它之上运行，这确实会影响它的外观和功能。 CLR 中支持商店应用程序 (WinRT) 的更改实际上是相当温和的。真正改变的是操作系统界面，就像 OSX 与 iOS 不同一样。如果您对平台不够了解，Microsoft 营销策略就会妨碍您。
在这种情况下，跨平台的主要区别是默认包含的库？那么，.NET Framework 具有基类库，而商店应用程序默认包含另一组库？除此之外，我认为 CLR 也存在差异。我们的想法是让框架针对其运行的不同环境（例如浏览器、手机或完整桌面）进行优化？
用于构建项目的参考程序集是最重要的。有很多很多不同的集合，例如，看看你的 c:\program files (x86)\reference 程序集目录的内容。
我看到了目录。这些是我们在 Visual Studio 中开发时使用的程序集，对吗？但是用于真正运行应用程序的程序集是我们部署应用程序的环境的 GAC 中可用的程序集，对吗？

【解决方案2】：

除了 .NET Framework，还有很多框架（.NET Framework、WinRT、UWP、Silverlight、.NET Core、Windows Phone、Mono、Micro Framework 和旧的 Compact Framework）。

新方法是针对支持一个或多个此类框架的平台标准进行编程。平台标准定义了与一个或多个框架匹配的 API。这意味着如果您的应用程序支持平台标准 1.1，您可能会支持几乎所有框架。平台标准 1.4 将仅支持 .NET Framework 4.6.x 和 .NET Core

看看这个文档：https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md

【讨论】：

【解决方案3】：

现在这完全让我感到困惑。但我总是：我们针对 .NET Framework 进行编码，无论如何，框架就是框架。

不，实际上有多个 .NET 框架或平台，您可以随意称呼它们。在 .NET Standard 之前，您曾经针对单个框架（如果您开发 Web 应用程序或 Windows 服务，则可能是完整的，当前版本为 4.6.3）。针对某个框架的 DLL 与另一个框架不兼容。 IE。为完整的 .NET 框架开发的 DLL 无法在 Windows phone 8.1 上执行。

这些框架实际上实现了一组非常小的通用库，但也实现了用于处理它们所针对的平台的特定库。 IE。用于管理托管在完整 .NET 框架中的 IIS 上的 Web 服务器的库，或用于在 windows phone 8.1 框架中处理手机的函数。

.NET Standard 之前是 PCL

虽然有一种解决方法，称为 PCL，它代表“可移植类库”。通过仅在两个或多个 .NET 框架中使用方法/程序集的一小部分公共子集，可以开发一个库，该库可以包含在针对不同框架的项目中。例如，PCL 配置文件 37 意味着您希望您的库可用于 .NET Framework 4、Silverlight 5 和 Windows 8 项目。

请查看此 PCL 配置文件列表及其兼容性（我不知道是否详尽）：http://danrigby.com/2014/05/14/supported-pcl-profiles-xamarin-for-visual-studio-2/

那么 .NET Standard 呢？

.NET Standard 的目标是简化这一点并摆脱 PCL。粗略地说，.NET Standard 定义了一个契约（一组类和方法），它将由所有 .NET 框架实现。如果您开发一个面向 .NET Standard 的库，那么您确信它可以在所有 .NET 框架上运行。这是它背后的基本想法/目标（尽管它有点微妙）。

看看这个确切的兼容性：https://blogs.msdn.microsoft.com/dotnet/2016/09/26/introducing-net-standard/#user-content-whats-new-in-net-standard-20

如果您查看兼容性表，您会发现面向 .NET Standard 1.6 的库可以在 .NET Framework 4.6.3 和 .NET Core 1.0 应用程序中按原样使用（无需重新编译）。

换句话说，我们可以说.NET Framework 4.6.3 和 .NET Core 1.0 都实现了 .NET Standard 1.6 契约：它的类和方法。

如果您还希望您的 DLL 在 windows phone 8.1 项目中可用，则必须以 .NET Standard 1.2 为目标，它提供的功能少于 .NET Standard 1.6（例如没有 System.Net.Sockets）。

在此处查看每个版本的 .NET Standard https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md#user-content-list-of-net-corefx-apis-and-their-associated-net-platform-standard-version 中可用命名空间的列表@

【讨论】：