logo标签列表

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

c#.netwindowsdnx.net-core
27

我正在尝试学习 .NET 平台标准，但对于“不同平台”的概念感到很困惑。

我将尽力阐述我的观点。目前我了解的 .NET Framework 大致由 CLR、BCL 和支持软件组成，用于引导 CLR 并提供虚拟机与底层操作系统之间的接口。

因此，当我们使用 .NET Framework 进行编码时，我们确实会针对某个版本的框架进行编程，因为我们从 BCL 中使用的类型是随着该框架提供的，所以其取决于特定版本。

现在，就我所理解的而言，.NET Core 则完全不同。它并非像这样打包在一起。我们有 CoreCLR，它是一个轻量级 VM 用于运行 IL；CoreFX，是经过适当组织的 NuGet 包库；还有 DNX/DNVM/DNU，提供支持性的东西，如引导 CoreCLR 和与 OS 的接口。

无论如何，即使我们在 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
  • Silverlight 4、5
  • 基于 .NET Framework 4.5.1 - 4.6 的 DNX
  • 基于 .NET Core 5.0 的 DNX

现在这完全把我搞糊涂了。我一直认为：我们针对 .NET Framework 进行编程，无论如何，框架就是框架。

但是这里有许多包括.NET框架在内的平台。例如，我们有Windows 8，但是等一下，将.NET运行在Windows 8上不仅仅意味着在任何其他操作系统上运行.NET？为什么它要与.NET Framework 2.0-4.6平台分开呢？

我们还有一个特定的平台DNX。这让我想知道：平台是指支持启动虚拟机并提供与操作系统接口相关的内容吗？还是平台包括虚拟机？

无论如何，可以看出我很困惑。这些平台到底是什么，以及它们如何与我现在对.NET Framework的了解相关联？另外，为什么.NET Framework 2.0-4.6被单独描述？除了.NET Core之外，难道不是这里描述的所有东西都是某个版本的.NET Framework吗？

.NET 中没有“虚拟机”。 - IInspectable
3
因此，最重要的是，无论你如何称呼这类软件（“虚拟机”还是“执行引擎”），CLR和JVM都属于同一类别。 - Rob
2
我一直认为CLR是一种虚拟机。这是一种软件，可以作为应用程序运行的沙盒。我们将IL字节码提供给这个虚拟机，其中包含的JIT编译器将生成本地代码并在特殊的沙盒上运行它。尽管我从未详细研究过CLR，但GitHub上的文档将其描述为“完整的高级虚拟机，旨在支持各种编程语言和它们之间的互操作性”。这使我相信我的粗略理解是合理的。 - user1620696
此文档中的“.NET Framework”是指通过MSI安装程序在机器范围内安装的非核心、非开源的.NET。它包括GAC（c:\windows\assembly）和编译器等（c:\windows\mictosoft.net\framework64\vX.X\）。 - Richard Szalay
是的@RichardSzalay，我通过版本猜到了。文档将其称为.NET Framework 2.0-4.6。但是，文档认为它是与Windows 8不同的平台。但是，在Windows 8或任何其他操作系统上运行.NET应用程序，我们需要安装相应的.NET Framework，对吧？因此，最终我们将在.NET Framework之上运行。我确实理解拆分.NET Full和.NET Core，但我不明白所有这些平台的想法。 - user1620696
显示剩余8条评论
3个回答
7
我们编写的代码是针对框架的。当您在代码中操作字符串时，您将始终使用System.String。它（几乎）总是以完全相同的方式具有完全相同的方法和属性。
但是，在显示字符串方面确实有实现细节，您不能真正忽略：
  • 如果您想在Linux或OSX上的Unix终端中显示它，则需要针对可以在这些操作系统上运行的框架实现Mono或CoreCLR。
  • 如果您想在Windows Store应用程序中显示它（也称为WinRT、Windows 8或UWP），则它实际上是一个HSTRING，在幕后非常隐蔽，您不必担心。但确实需要一个UI小工具，如Windows.UI.Xaml.Controls.TextBlock，这是一个高度特定于WinRT的类。
  • 如果您想在浏览器中显示它，则需要针对ASP.NET或Silverlight进行目标化，这些框架主机被优化为在Web服务器或作为浏览器的插件运行。
  • 如果您想在由小型锂离子电池供电的设备上显示它，例如手机，则不可避免地必须处理针对尽可能少使用电力的框架版本。这确实会影响您必须编写的代码，烧掉100瓦和让小电池保持活力8小时之间有很大的差异。您需要针对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已经全部具备了这些功能，因此它是一个特定的平台。但是，为了开发商店应用程序，例如，就会构建一个新的运行时环境，使用新的基本库集和新的支持软件，对于所有这些垂直领域都是如此？ - user1620696
我故意避免发布那个图表，因为在我看来它并没有真正帮助。底层最重要，.NET 必须在其上运行，这会影响它的外观和功能。CLR 为支持存储应用程序（WinRT）所做的更改实际上相当温和。真正改变的是操作系统界面，就像 OSX 与 iOS 不同一样不同。如果你不够了解平台，微软的营销策略会妨碍你的视野。 - Hans Passant
在这种情况下，跨平台的主要区别是默认包含的库吗？因此，.NET Framework具有基类库，而商店应用程序具有另一组默认包含的库？除此之外，我认为CLR也存在差异。而且，理念是使框架针对将运行的不同环境进行优化（例如浏览器、电话或完整桌面）？ - user1620696
你构建项目所使用的参考程序集是最重要的。有很多不同的程序集，例如可以看一下你的 c:\program files (x86)\reference assemblies 目录中的内容。 - Hans Passant
我看到了目录。这些是我们在Visual Studio开发中使用的程序集，对吗？但真正运行应用程序所使用的程序集是部署应用程序的环境中GAC可用的那些程序集，对吗？ - user1620696
也许吧。更多的实现细节被很好地隐藏起来了，CoreCLR或Silverlight或Store或UWP应用程序并不使用GAC。后两者根本不使用框架，而是通过.NET Native内置到包中。 - Hans Passant
5

有许多框架（.NET Framework、WinRT、UWP、Silverlight、.NET Core、Windows Phone、Mono、Micro Framework 和旧的 Compact Framework），而不仅仅是 .NET 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

5
现在这让我非常困惑。我一直认为：我们针对.NET Framework编码，而框架就是框架，无论如何都是一样的。不，实际上有多个.NET框架或平台，或者您喜欢称之为平台。在.NET标准之前，您需要针对单个框架进行开发（可能是完整版本，目前为4.6.3版本，如果您开发Web应用程序或Windows服务）。针对框架的DLL与另一个框架不兼容。例如，为完整.NET框架开发的DLL无法在Windows Phone 8.1上执行。
这些框架实际上实现了一组非常小的公共库，还有用于处理所预期平台的特定库。例如，在完整的.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。
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接