. NET Core和. NET标准类库项目类型有什么区别？

什么时候我们应该使用一个而不是另一个？

该决定是兼容性和API访问之间的权衡。

如果您想增加与您的库兼容的应用程序的数量，并且可以减少您的库可以访问的. NET API表面积，请使用. NET标准库。

当您想要增加您的库可以访问的. NET API表面积时，请使用. NET Core库，并且您可以只允许. NET Core应用程序与您的库兼容。

例如，以. NET Framework 4.6、. NET Core 1.0、Universal Windows Platform 10.0和任何其他支持. NET Standard 1.3的平台为目标的. NET Standard 1.3将与应用程序的库。但是，该库将无法访问. NET API的某些部分。例如，Microsoft.NETCore.CoreCLR包与. NET Core兼容，但与. NET Standard不兼容。

类库（. NET Standard）和类库（. NET Core）有什么区别？

兼容性：以. NET Standard为目标的库将在任何符合. NET Standard的运行时上运行，例如. NET Core、. NET Framework、Mono/Xamarin。另一方面，以. NET Core为目标的库只能在. NET Core运行时上运行。

API表面积：. NET Standard库包含NETStandard.Library中的所有内容，而. NET Core库包含Microsoft.NETCore.App中的所有内容。后者包括大约20个额外的库，其中一些我们可以手动添加到我们的. NET Standard库（例如System.Threading.Thread），其中一些与. NET Standard不兼容（例如Microsoft.NETCore.CoreCLR）。

此外，. NET Core库指定了运行时并附带了应用程序模型。例如，这对于使单元测试类库可运行很重要。

为什么两者都存在？

暂时忽略库，. NET Standard存在的原因是可移植性；它定义了一组. NET平台同意实现的API。任何实现. NET Standard的平台都与以. NET Standard为目标的库兼容。其中一个兼容平台是. NET Core。

回到库，. NET标准库模板的存在是为了在多个运行时上运行（以牺牲API表面积为代价）。相反，. NET Core库模板的存在是为了访问更多的API表面积（以牺牲兼容性为代价）并指定用于构建可执行文件的平台。

这是一个交互式矩阵，显示哪个. NET Standard支持哪个. NET实现以及可用的API表面积。

. NET和. NET Core是. NET运行时的两种不同实现。Core和Framework（尤其是Framework）都有不同的配置文件，其中包括Microsoft为. NET创建的许多API和程序集的较大或较小（或完全不同）的选择，具体取决于它们的安装位置和配置文件。

例如，通用Windows应用程序中的API与“普通”Windows配置文件中的API不同。即使在Windows上，您也可能拥有“客户端”配置文件与“完整”配置文件。此外，还有其他实现（如Mono）拥有自己的库集。

. NET标准是一组API库和程序集必须可用的规范。为. NET Standard 1.0编写的应用程序应该能够使用任何版本的Framework、Core、Mono等编译和运行，这些版本宣传支持. NET Standard 1.0库集合。. NET Standard 1.1、1.5、1.6、2.0等也是如此。只要运行时为您的程序所针对的Standard版本提供支持，您的程序就应该在那里运行。

针对Standard版本的项目将无法使用该标准修订版中未包含的功能。这并不意味着您不能依赖于其他程序集或其他供应商发布的API（即：NuGet上的项目）。但这确实意味着您采用的任何依赖项还必须包括对您的. NET Standard… NET Standard版本的支持。NET Standard正在快速发展，但它仍然足够新，并且足够关心一些较小的运行时配置文件，这种限制可能会令人窒息。（请注意一年半之后：这种情况开始发生变化，最近的. NET Standard版本更好，功能更全面）。

另一方面，针对Standard应该的应用程序能够在更多的部署情况下使用，因为理论上它可以与Core、Framework、Mono等一起运行。对于一个寻求广泛分发的类库项目，这是一个有吸引力的承诺。对于主要面向内部受众的以最终用户为中心的项目，这可能不是那么令人担忧。

. NET Standard在系统管理员团队出于哲学或成本原因希望从Windows上的ASP.NET转移到Linux上的. NET CoreASP.NET的情况下也很有用，但开发团队希望继续在Windows上的Visual Studio中使用. NET Framework。

简短的回答是：

IAnimal == .NetStandard (General)ICat == .NetCore (Less general)IDog == .NetFramework (Specific / oldest and has the most features)

. NET核心类库建立在. NET标准之上。如果您想实现一个可移植到. NET Framework、. NET Core和Xamarin的库，请选择. NET标准库

. NET Core最终将实现. NET Standard 2（如Xamarin和. NET Framework）

因此，. NET Core、Xamarin和. NET Framework可以被识别为. NET标准中的口味

为了使您的应用程序面向未来以进行代码共享和重用，您宁愿实现。NET标准库。

Microsoft还建议您使用. NET标准而不是便携式类库。

引用MSDN作为权威来源，. NET标准意在一个图书馆统治他们所有人。由于图片胜过千言万语，以下内容将使事情变得非常清楚：

1.你当前的应用场景（碎片化）

像我们大多数人一样，你可能会遇到以下情况：（. NET Framework、Xamarin和现在的. NET Core风格的应用程序）

2… NET标准库将为您提供什么（跨框架兼容性）

实现. NET标准库允许跨所有这些不同风格的代码共享：

不耐烦的人：

1. . NET标准解决了. NET开发人员在所有平台上的代码共享问题，将您期望和喜爱的所有API带到您需要的环境中：桌面应用程序、移动应用程序和游戏以及云服务：
2. . NET标准是一组API，所有。NET平台必须执行。这统一. NET平台和防止未来的碎片化。
3. . NET Standard 2.0将由. NET Framework，.NET Core实现，和Xamarin。对于. NET Core，这将添加许多现有的API已被要求。
4. . NET Standard 2.0包括. NET Framework二进制文件的兼容性垫片，显着增加了您可以从. NET标准库中引用的库集。
5. . NET标准将取代便携式类库（PCL）作为用于构建多平台的工具故事。NET库。

对于一个表，以帮助了解您可以针对的最高版本的. NET Standard，基于您打算在其上运行的. NET平台，到这里来。

来源：MSDN：介绍. NET标准

. NET Standard的存在主要是为了改进代码共享并使每个. NET实现中可用的API更加一致。

在创建库时，我们可以将目标设置为. NET Standard 2.0，以便创建的库与不同版本的. NET Framework兼容，包括. NET Core、Mono等。

. NET Standard：将其视为一个大型标准库。将其用作依赖项时，您只能生成库（. DLL），而不能生成可执行文件。使用. NET标准作为依赖项创建的库可以添加到Xamarin. Android、Xamarin. iOS、. NET Core Windows/OS X/Linux项目中。

. NET Core：把它看作是旧的. NET框架的延续，只是它是开源的，有些东西还没有实现，有些东西已经被弃用了。它用额外的功能扩展了. NET标准，但它只能在桌面上运行。当添加它作为依赖项时，你可以在Windows、Linux和OS X上制作可运行的应用程序。（虽然现在只是控制台，没有GUI）。所以. NET Core=. NET Standard+桌面特定的东西。

UWP也使用它，新的ASP.NET核心也使用它作为依赖项。

. NET Framework和. NET Core都是框架。

. NET Standard是一种标准（换句话说，一种规范）。

您可以使用. NET Framework和. NET Core创建可执行项目（如控制台应用程序或ASP.NET应用程序），但不能使用. NET Standard。

使用. NET Standard，您只能创建不能独立执行且应由另一个. NET Core或. NET Framework可执行项目引用的类库项目。

我希望这将有助于理解. NET Standard API表面和其他. NET平台之间的关系。每个接口代表一个目标框架，方法代表该目标框架上可用的API组。

namespace Analogy{// .NET Standard
interface INetStandard10{void Primitives();void Reflection();void Tasks();void Xml();void Collections();void Linq();}
interface INetStandard11 : INetStandard10{void ConcurrentCollections();void LinqParallel();void Compression();void HttpClient();}
interface INetStandard12 : INetStandard11{void ThreadingTimer();}
interface INetStandard13 : INetStandard12{//.NET Standard 1.3 specific APIs}
// And so on ...

// .NET Framework
interface INetFramework45 : INetStandard11{void FileSystem();void Console();void ThreadPool();void Crypto();void WebSockets();void Process();void Drawing();void SystemWeb();void WPF();void WindowsForms();void WCF();}
interface INetFramework451 : INetFramework45, INetStandard12{// .NET Framework 4.5.1 specific APIs}
interface INetFramework452 : INetFramework451, INetStandard12{// .NET Framework 4.5.2 specific APIs}
interface INetFramework46 : INetFramework452, INetStandard13{// .NET Framework 4.6 specific APIs}
interface INetFramework461 : INetFramework46, INetStandard14{// .NET Framework 4.6.1 specific APIs}
interface INetFramework462 : INetFramework461, INetStandard15{// .NET Framework 4.6.2 specific APIs}
// .NET Coreinterface INetCoreApp10 : INetStandard15{// TODO: .NET Core 1.0 specific APIs}// Windows Universal Platforminterface IWindowsUniversalPlatform : INetStandard13{void GPS();void Xaml();}
// Xamarininterface IXamarinIOS : INetStandard15{void AppleAPIs();}
interface IXamarinAndroid : INetStandard15{void GoogleAPIs();}// Future platform
interface ISomeFuturePlatform : INetStandard13{// A future platform chooses to implement a specific .NET Standard version.// All libraries that target that version are instantly compatible with this new// platform}
}

来源