.Net Core，Portable，Standard，Compact，UWP和PCL之间的区别？

Question

我听说过

• .Net Core
• .Net Portable
• .Net Standard
• .Net Compact
• 通用Windows平台
• 便携式类库

所有这些都被解释为“完整.Net的一个子集，允许您定位多个平台”。所以我的问题是

1. 有什么区别！
2. 如果我想编写一个可供尽可能多的受众群体使用的库，我需要使用哪一个（或多个）？

（我的具体情况：我有a library针对.Net 2.0，.Net 4.5和UWP。定位UWP需要创建一个新的VS项目并链接所有现有文件，这是一个巨大的现在有人告诉我它对PCL不起作用，从它的声音我不得不再为.Net标准做了！？）

Answer 1

我先回答你的第二个问题：

  

我有一个以.Net 2.0，.Net 4.5和UWP为目标的库。针对UWP需要创建一个新的VS项目并链接所有现有文件，这是一个巨大的痛苦。现在有人告诉我它不适用于PCL，从它的声音我不得不再为.Net标准做了！？）

     

如果我想编写一个可供大量观众使用的图书馆，我需要使用哪一个（或多个）？

简短回答：你应该定位netstandard。使用包含所需API的lowest version。您可以使用API Port到check your existing project for compatibility with a given netstandard version等工具。

不幸的是，这种方法将留下旧版平台，在您的情况下，.NET 2.0。如果需要维护.NET 2.0支持，那么您需要一个单独的项目（带有链接文件）来构建单独的.NET 2.0程序集。

详细信息......

  

有什么区别！？

• .Net Standard （netstandard） - 这是新的跨平台BCL API。这是一个＆＃34;标准＆＃34;从某种意义上说，它只是一个API定义，而不是一个实现。我们的想法是，您可以将您的库编译为此API的（版本），它将在支持该版本的任何平台上运行。
• .Net Core - 您可以将其视为netstandard的参考实现（带有一些额外的位）。它是该API的跨平台实现。 UI和其他框架可能构建在它上面，但是现在它唯一可靠的立足点是作为ASP.NET Core的首选平台。 [旁注：由于历史原因，＆＃34; .NET Core＆＃34; 与<{1}} NuGet目标完全不同;当您进入NuGet上下文时，netcore means "Windows 8/8.1/10"]。
• .Net Portable 和可移植类库 - 可移植类库（PCL）是提供跨平台API的最常见分母方法。它们涵盖wide range of target platforms，但它们不完整且不具备前瞻性。它们基本上已被netcore替换。
• .Net Compact - 这是一个完全不同的.NET框架，它有自己独特的API。它与任何其他框架，PCL或netstandard版本完全不兼容;因此，支持比任何其他平台都困难得多。但是，它仍然用在内存限制严重的设备上。
• 通用Windows平台 - 这是Windows Phone和桌面之间的Win10时代的API合并，允许为两个平台编写Windows应用商店应用/库。这基本上已被netstandard取代。

Answer 2

正如评论中所链接的那样，already a description by Microsoft概述了所有这些信息。但是，根据您的回答，您似乎并没有完全理解整个事情。它的非常很长，所以这里（希望）是一个tl; dr版本。

我们将从上面的链接开始以下表格，希望这可以解决一些混乱：

对于后来发现这一点的其他人的简要概述：.NET库在其存在的15年中已经超越了批次的变更和端口。在那个时候，许多智能手机现在几乎和2001年使用的一些桌面一样强大。在那个intermin中，subsets of the .NET framework were created (and quickly abandoned)用于不同的平台。使用Satya Nadella的新方法使.NET成为一个尽可能广泛的平台，需要改变。

作为一项已有15年历史的技术，需要改进。 .NET Core自2014年以来一直作为.NET架构的彻底检修进行过工作。它已经从头开始重写为.NET语言的新版本。 Core的目标之一是实现跨平台部署。无论是在iPhone / Android / XBox One上运行的应用程序，还是可以在IIS或Linux机器上托管的网站，.NET Core都能满足您的需求。它通过几种不同的方式实现这一点，包括不需要在机器上安装.NET Framework，而是使用您的解决方案打包必要的库。

最值得注意的是，.NET Core是对ASP.NET的重大改变。旧的System.Web完全消失并重写为as performant as possible with impressive results。单独的WebApi控制器已经消失，因为一切都在一个控制器内完成。整个过程现在是选择加入，而不是默认允许你可能不想要的东西。

但是，我们作为开发人员最终会想要迁移一些应用程序，所以我们怎样才能确保我们已编写的代码没有对方法进行一些小的名称更改，从而打破了编译巨型解决方案 来自 .NET标准。这是一组必须实现的API，以便您的平台自己调用＆＃34; .NET＆＃34;。

作为基本的 .NET Framework ，我们多年来一直与之合作已经很成熟，它被用作标准所涵盖的基础。但是，一切都不包括在内，重点是什么？因此，标准只是各种类型的.NET平台之间存在的通用API。 您最终不会在＆＃34; .NET Standard＆＃34;中编写代码。

2016年，Xamarin（包含在上表中）为purchased by Microsoft，该技术用于帮助构建（或至少激发）.NET Core跨平台。它仍然作为一种工具存在，但与过去使用的静脉相同。根据该表，它将在vNext版本中符合.NET Standard 2.0标准。但是，它的目标受众不会改变。

要直接回答您的问题，如果您想使用尽可能广泛的单一部署解决方案编写应用程序，则需要使用 .NET Core 。但是，如果您正在使用当前基于.NET Framework 2.0和4.5构建的库，那么您将无法使用 .NET Framework 并且具有单独的 UWP 该目标的解决方案。

如果它提供了可以通过Web API调用调用的内容，则可以在.NET Framework中的服务器上运行该调用，并在.NET Core中使用单个解决方案来部署到最终用户。如果它已集成到您的代码中，那么在您提供.NET Core更新之前，遗憾的是运气不佳。

希望这可以消除不同技术名称之间的一些混淆。

修改

在对您的具体情况作出一些澄清之后，我可以为您解决问题。您可以不制作一个同时针对.NET Framework和.NET Core的解决方案。使用不同的底层技术以完全不同的方式进行编译，因此这与尝试在.NET 2.0解决方案中使用.NET 4.5版本的情况相同。

但是，有tutorials允许您将项目移植到Core。在大多数情况下，只需将类主体复制到.NET Core解决方案中，大多数东西都能正常工作。有些作品已经被废弃，有些作品还没有完全100％充实（不是你的情况，但实体框架并没有例如所有相同的功能）。还有一些电话已经改变了一点。

好的新东西是向前发展，.NET Core将为您提供最广泛的覆盖范围。 .NET Framework不会消失，但它和Core将更加同步。

.NET Core的另一个好处是它使用迭代方法进行部署，因此您无法等待2年的下一次重大升级。通过NuGet提供的一切，您将在改进和新功能方面有更快的周转时间。