目前正在尝试学习.NET平台标准，我发现自己对“不同平台”的想法感到困惑。
我会尽力使我的观点清楚。 我现在对.NET Framework的介绍是，.NET大致上是由CLR，BCL和支持软件组成的，用来启动CLR并提供虚拟机和底层操作系统之间的接口。
所以，当我们使用.NET框架进行编码时，我们确实定位了某个版本的框架，因为我们从BCL中使用的types随框架一起提供，因此取决于特定的版本。
现在，.NET Core与我所了解的完全不同。 这不是全部包装在一起。 我们有CoreCLR，它是一个轻量级的虚拟机来运行IL，CoreFX，这些库是正确组织的NuGet包，我们到目前为止提供了支持的东西，如引导CoreCLR和接口的DNX / DNVM / DNU OS。
types“System.Idisposable”在未引用的程序集中定义
Windows服务需要等待，Thread.Sleep？
确定是否在.NET中共享文件夹
为什么winform面板仅在鼠标hover或鼠标点击时更新？
如何testing远程UDP端口
无论如何，尽pipe我们在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上的DNX – 4.6
.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 Framework的一些版本，除非.NET Core？
环境variables强制.NET应用程序运行为32位
.NET FileInfo.LastWriteTime和FileInfo.LastAccesstime是错误的
依次读取大量的小文件
.NET Windows服务 – 一个项目中的多个服务
我们对这个框架进行编码。
那么，确定你是。 当你在你的代码中操作字符串时，你总是会使用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上使用的一种技巧来启动CLR虚拟机。 这需要dnx.exe，就像使用java.exe或python.exe来编写用Java或Python编写的程序一样。
如果这些实施细节不重要，那将是可爱的。 但并不是它在实践中的工作方式，随着.NET在越来越多的设备和操作系统上的普及和使用，它不可避免地变得更加复杂。 尽早选择你想要的目标，这很重要。
有许多框架（.NET Framework，WinRT，UWP，Silverlight，.NET Core，Windows Phone，Mono，Micro Framework和旧的Compact Framework）不仅仅是.NET框架。
新方法是针对支持一个或多个框架的平台标准进行编程。 平台标准定义了一个匹配一个或多个框架的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
现在这完全混淆了我。 我总是：我们对.NET Framework进行编码，框架无论如何都是框架。
不，实际上有多个.NET框架或平台，你可以称之为。 在.NET Standard之前，您曾经使用过一个框架（如果您开发Web应用程序或Windows服务，可能是完整的，目前版本为4.6.3）。 面向框架的DLL与另一个不兼容。 IE为全.NET框架开发的DLL无法在Windows Phone 8.1上执行。
这些框架实际上实现了一个相当小的通用的馆藏集，而且还有专门的图书馆来处理他们打算的平台。 用于在完整.NET框架中管理托管在IIS上的Web服务器的IE库，或用于在Windows Phone 8.1框架中处理移动电话的函数。
@H_404_87@在.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-视觉工作室-2 /
@H_404_87@那么.NET标准呢？
.NET标准的目标是简化这个并摆脱PCLs。 粗略地说，.NET标准定义了一个契约（一组类和方法），将由所有.NET框架实现。 如果你开发一个面向.NET标准的库，你可以确定它可以运行在所有的.NET框架上。 这是它背后的基本思想/目标（尽管它有点微妙）。
看看这个确切的兼容性： https ： //blogs.msdn.microsoft.com/dotnet/2016/09/26/introducing-net-standard/#user-content-whats-new-in-net-standard -20
如果您查看兼容性表，您将看到在.NET Framework 4.6.3和.NET Core 1.0应用程序中，以.NET Standard 1.6为目标的库可按原样使用（无需重新编译它）。
换句话说，我们可以说@H_404[email protected] 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标准中可用的命名空间的列表https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md#user-content-list-of -net-corefx的API，和其相关的净平台标准版
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 [email protected] 举报，一经查实，本站将立刻删除。
