.NET Core和.NET Standard Class Library项目types有什么区别？
在Visual Studio中，至less有三种不同types的类库可以创build：
- 类库（.NET Framework）
- 类库（.NET标准）
- 类库（.NET Core）
虽然第一个是我们多年来一直使用的，但我一直在使用.NET标准和.NET核心类库types的主要困惑。 我最近在尝试多目标不同的框架版本 ，并创build一个unit testing项目时，一直被这个问题困住了。
那么， Class Library (.NET Standard)和Class Library (.NET Core)什么不同，为什么两者都存在，我们应该什么时候使用它们呢？
我们什么时候应该使用一个呢？
这个决定是在兼容性和API访问之间取舍的。
如果要增加与您的库兼容的应用程序的数量，请使用.NET标准库，并且可以减less库的可访问的.NET API表面积。
如果要增加库的访问权限，可以使用.NET Core库，只允许.NET Core应用程序与库兼容，那么可以。
例如，面向.NET标准1.3的库将与面向.NET Framework 4.6，.NET Core 1.0，通用Windows平台10.0和任何其他支持.NET Standard 1.3的平台的应用程序兼容 。 但是，图书馆将无法访问.NET API的某些部分。 例如， Microsoft.NETCore.CoreCLR包与.NET Core兼容，但与.NET Standard不兼容。
类库（.NET标准）和类库（.NET Core）有什么区别？
这里基于包的框架部分描述了这个区别。
兼容性：以.NET标准为目标的库将运行在任何符合.NET标准的运行时，如.NET Core，.NET Framework，Mono / Xamarin。 另一方面，以.NET Core为目标的库只能在.NET Core运行时上运行。
API表面区域：.NET标准库带有NETStandard.Library所有内容，而.NET Core库带有Microsoft.NETCore.App所有内容。 后者包括大约20个额外的库，其中一些可以手动添加到我们的.NET标准库（例如System.Threading.Thread ），其中一些库与.NET标准（例如Microsoft.NETCore.CoreCLR ）。
此外，.NET核心库指定了一个运行时间并附带一个应用程序模型。 例如，使unit testing类库可以运行是很重要的。
为什么两者都存在？
暂时忽略库，.NET标准存在的原因是可移植性; 它定义了一系列.NET平台同意实现的API。 任何实现.NET标准的平台都与以.NET标准为目标的库兼容。 这些兼容的平台之一是.NET核心。
回到库，.NET标准库模板存在运行在多个运行时（以API表面面积为代价）。 相反，存在.NET Core库模板来访问更多的API表面区域（以牺牲兼容性为代价）并指定构build可执行文件的平台。
TL; DR .Net核心类库是build立在.Net标准之上的。 如果你想实现一个可移植到.Net Framework的库， Net Core和Xamarin ，select一个.Net标准库
.Net Core将最终实现.Net Standard 2 （和Xamarin和.Net框架一样 ）
.Net Core ， Xamarin和.Net Framework可以被视为.Net Standard的 风格
为了使您的应用程序可以进行代码共享和重用，您宁愿实施.Net标准库。
Microsoft还build议您使用.NET标准而不是可移植类库 。
引用MSDN作为一个权威的来源， .Net标准打算成为一个统治它们的图书馆 。 由于图片胜过千言万语，以下内容将使事情变得非常清楚：
1.您当前的应用场景（分段）
像我们大多数人一样，您可能处于以下情况：（.Net Framework，Xamarin和现在的.Net Core风格的应用程序）
2. .Net标准库将为您提供什么（跨框架兼容性）
实现.Net标准库允许代码共享所有这些不同的风格：
对于急躁：TL; DR
- .NET Standard解决了所有平台上的.NET开发人员的代码共享问题，它将您期望和喜爱的所有API用于所需的环境：桌面应用程序，移动应用程序和游戏以及云服务：
- .NET标准是一组 所有 .NET平台必须实现 的API 。 这将统一.NET平台，并防止未来的碎片化 。
- .NET标准2.0将由.NET Framework实现。 NET Core和Xamarin 。 对于.NET Core ，这将添加许多已经请求的现有API。
- .NET标准2.0包含一个用于.NET Framework二进制文件的兼容性填充，大大增加了可从.NET标准库中引用的一组库。
- .NET Standard 将取代可移植类库（PCL），作为构build多平台.NET库的工具。
要获得一个表格来帮助你理解基于你打算运行哪个.NET平台的最高版本的.NET Standard，你可以在这里find 。
来源： MSDN：介绍.Net标准
所以简短的答案是：
IAnimal == .NetStandard (General) IBird == .NetCore (Less General) IEagle == .NetFramework (Specific / oldest and has the most features)
.Net Framework和.Net Core是.Net运行时的两种不同实现。 核心和框架（但特别是框架）有不同的configuration文件，包括微软为.Net创build的许多API和程序集的更大或更小（或简单地不同）select，取决于它们的安装位置和configuration文件。 例如，通用Windows应用程序中有一些不同于“正常”Windowsconfiguration文件的API。 即使在Windows上，您也可能拥有“客户端”configuration文件与“完整”configuration文件。 此外，还有其他的实现（如Mono）有自己的一套库。
.Net Standard是一个API库和程序集必须可用的规范。 为.Net标准1.0编写的应用程序应该能够编译和运行任何版本的Framework，Core，Mono等广告支持.Net Standard 1.0库集合。 .Net标准1.1,1.5,1.6,2.0等也是如此。只要运行时支持该版本的标准，您就可以在那里编译和运行。
针对标准版本的项目将无法使用该标准修订版中未包含的function。 这并不意味着你不能依赖于其他程序集或其他供应商发布的API（即：NuGet上的项目）。 但是这确实意味着你所依赖的任何依赖也必须包括对你的.Net标准版本的支持。 .net标准正在快速发展，但它仍然是新的，并且对一些较小的运行时configuration文件足够关心，这个限制会让人感到窒息。
另一方面，针对Standard的应用程序应该可以用于更多的部署情况，因为理论上它可以运行在Core，Framework，Mono等等上。对于一个寻求广泛分布的类库项目，这是一个有吸引力的承诺。 对于主要用于内部目的的类图书馆项目来说，可能不是那么关心。
.Net标准主要是为了改善代码共享，并使每个.Net实现中的API更加一致。
在创build库的时候，我们可以把目标设定为.Net Standard 2.0，这样就可以创build一个与.Net Framework不同版本的.Net Core，包括.Net Core，Mono。
