.NET Core 和 .NET Standard 类库项目类型之间有什么区别？

Question

在 Visual Studio 中，您可以创建至少三种不同类型的类库：

• 类库（.NET 框架）
• 类库（.NET 标准）
• 类库 (.NET Core)

虽然第一个是我们多年来一直在使用的，但我一直遇到的一个主要困惑点是何时使用 .NET Standard 和 .NET Core 类库类型。 我最近在尝试针对不同的框架版本进行多目标定位并创建单元测试项目时被这个问题所困扰。

那么，类库 (.NET Standard)和类库 (.NET Core)之间有什么区别，为什么两者都存在，我们什么时候应该使用一个？

Answer 1

我们什么时候应该使用一个？

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

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

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

例如，面向 .NET Standard 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 Standard) 和类库 (.NET Core) 有什么区别？

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

API Surface Area：.NET Standard 库随NETStandard.Library所有内容一起NETStandard.Library ，而 .NET Core 库随Microsoft.NETCore.App所有内容一起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 Standard 库模板可以在多个运行时上运行（以 API 表面积为代价）。 相反，.NET Core 库模板的存在是为了访问更多 API 表面区域（以牺牲兼容性为代价）并指定一个平台来构建可执行文件。

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

Answer 2

.NET Core 类库基于.NET Standard构建。 如果要实现可移植到.NET Framework 、 .NET Core和Xamarin 的库，请选择.NET Standard Library

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

因此， .NET Core 、 Xamarin和.NET Framework可以被识别为.NET Standard 的风格

为了让您的应用程序面向未来以实现代码共享和重用，您宁愿实现 .NET Standard 库。

Microsoft 还建议您使用.NET Standard而不是Portable Class Libraries 。

引用 MSDN 作为权威来源， .NET Standard旨在成为一个库来统治所有。 由于图片值一千字，以下内容将使事情变得非常清楚：

1、你目前的应用场景（碎片化）

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

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

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

对于不耐烦的人：

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

如需帮助了解基于您打算在哪些 .NET 平台上运行的最高版本的 .NET Standard，您可以定位的最高版本的表格，请转到此处。

来源： MSDN：介绍 .NET 标准

Answer 3

简短的回答是：

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

Answer 4

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

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

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

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

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

在系统管理员团队出于哲学或成本原因希望从 Windows 上的 ASP.NET 迁移到 Linux 上的 .NET Core 的 ASP.NET，但开发团队希望继续针对 . NET Framework 在 Windows 上的 Visual Studio 中。

Answer 5

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

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

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

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

Answer 6

我希望这有助于理解.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 Core
    interface INetCoreApp10 : INetStandard15
    {
        // TODO: .NET Core 1.0 specific APIs
    }
    // Windows Universal Platform
    interface IWindowsUniversalPlatform : INetStandard13
    {
        void GPS();
        void Xaml();
    }

    // Xamarin
    interface 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
    }

}

来源

Answer 7

另一种解释差异的方法可能是使用现实世界的例子，因为我们大多数人都会使用现有的工具和框架（ Xamarin 、 Unity等）来完成这项工作。

因此，使用 .NET Framework，您可以使用所有 .NET 工具，但您只能针对 Windows 应用程序（ UWP 、 Windows Forms 、 ASP.NET等）。 由于 .NET Framework 是封闭源代码，因此没有太多可做的。

使用 .NET Core，您拥有的工具更少，但您可以针对主要桌面平台（Windows、Linux 和 Mac）。 这在 ASP.NET Core 应用程序中特别有用，因为您现在可以在 Linux 上托管 ASP.NET（托管价格更便宜）。 现在，由于 .NET Core 是开源的，因此在技术上可以为其他平台开发库。 但是由于没有支持它的框架，我认为这不是一个好主意。

使用 .NET Standard，您拥有的工具更少，但您可以针对所有/大多数平台。 借助 Xamarin，您可以定位移动设备，借助 Mono/Unity，您甚至可以定位游戏机。 也可以使用 UNO 平台和Blazor来定位 Web 客户端（尽管现在两者都处于试验阶段）。

在实际应用程序中，您可能需要使用所有这些。 例如，我开发了一个具有以下架构的销售点应用程序：

共享服务器和静默：

• 处理我的应用程序模型的 .NET Standard 库。
• 一个 .NET Standard 库，用于处理客户端发送的数据的验证。

由于它是一个 .NET Standard 库，因此可以在任何其他项目（客户端和服务器）中使用。

在 .NET 标准库上进行验证也是一个很好的优势，因为我可以确定在服务器和客户端上应用了相同的验证。 服务器是强制性的，而客户端是可选的，可用于减少流量。

服务器端（Web API）：

• 处理所有数据库连接的 .NET Standard（也可以是 .NET Core）库。

• 处理 Rest API 并使用数据库库的 .NET Core 项目。

由于这是在 .NET Core 中开发的，因此我可以在 Linux 服务器上托管该应用程序。

客户端（带有WPF + Xamarin.Forms Android/iOS 的MVVM ）：

• 处理客户端 API 连接的 .NET Standard 库。

• 处理ViewModels 逻辑的.NET Standard 库。 它用于所有视图。

• 一个 .NET Framework WPF 应用程序，用于处理 Windows 应用程序的 WPF 视图。 WPF 应用程序现在可以是 .NET 核心，尽管它们目前只能在 Windows 上运行。 AvaloniaUI 是为其他桌面平台制作桌面GUI 应用程序的不错选择。

• 处理 Xamarin 表单视图的 .NET Standard 库。

• Xamarin Android 和 Xamarin iOS项目。

所以你可以看到在应用程序的客户端有一个很大的优势，因为我可以重用 .NET Standard 库（客户端API 和 ViewModels），并且只为 WPF、Xamarin 和 iOS 应用程序创建没有逻辑的视图。

Answer 8

.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 Core 也将它用作依赖项。

Answer 9

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

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

Answer 10

之前的答案可能描述了对 .NET Core、.NET Standard 和 .NET Framework 之间区别的最佳理解，所以我只想分享我在选择它时的经验。

在需要混合使用 .NET Framework、.NET Core 和 .NET Standard 的项目中。 例如，在我们使用 .NET Core 1.0 构建系统时，不支持使用 .NET Core 托管 Window Services。

下一个原因是我们使用了不支持 .NET Core 的 Active Report。

所以我们想要构建一个可以同时用于 .NET Core (ASP.NET Core) 和 Windows Service and Reporting (.NET Framework) 的基础架构库 -> 这就是我们为这种库选择 .NET Standard 的原因。 选择 .NET 标准意味着您需要仔细考虑库中的每个类都应该简单且跨 .NET（核心、框架和标准）。

结论：

• .NET Standard 用于基础结构库和共享通用。 这个库可以被 .NET Framework 和 .NET Core 引用。
• .NET Framework 用于不受支持的技术，如 Active Report、Window Services（现在支持 .NET 3.0）。
• .NET Core 当然是 ASP.NET Core。

微软刚刚宣布 .NET 5：引入 .NET 5

Answer 11

.NET 框架

Windows 窗体、ASP.NET 和 WPF 应用程序必须使用 .NET Framework 库开发。

.NET 标准

Xamarin、iOS 和 Mac OS X 应用程序必须使用 .NET Standard 库开发

.NET 核心

必须使用 .NET Core 库开发通用 Windows 平台(UWP) 和 Linux 应用程序。 API 是用 C++ 实现的，您可以使用 C++、VB.NET、C#、F# 和 JavaScript 语言。NET

Answer 12

.Net核心类库基于.Net标准构建。 如果要实现可移植到.Net Framework，.Net Core和Xamarin的库，请选择.Net标准库

Answer 13

.NET Core .NET Core是托管框架的免费、跨平台、开源实现。 它支持四种类型的应用程序：控制台、ASP.NET Core、云和通用 Windows 平台 (UWP)。 Windows 窗体和 Windows Presentation Foundation (WPF) 不是 .NET Core 的一部分。

从技术上讲，.NET Core 仅支持控制台应用程序。 ASP.NET Core 和 UWP 是构建在 .NET Core 之上的应用程序模型。

与 .NET Framework 不同，.NET Core 不被视为 Windows 组件。 因此，更新以 NuGet 包的形式出现，而不是通过 Windows 更新。 由于 .NET Core 运行时安装在 App-Local 中，并且应用程序通过包管理器进行更新，因此应用程序可以与特定的 .NET Core 版本相关联并单独更新。

.NET Standard托管框架的每个实现都有自己的一组基类库。 基类库 (BCL) 包含异常处理、字符串、XML、I/O、网络和集合等类。

.NET Standard是用于实现 BCL 的规范。 由于 .NET 实现需要遵循此标准，因此应用程序开发人员不必担心每个托管框架实现的 BCL 版本不同。

框架类库 (FCL)（例如 WPF、WCF 和 ASP.NET）不是 BCL 的一部分，因此不包含在 .NET Standard 中。

.NET Standard 和 .NET 实现之间的关系与 HTML 规范和浏览器之间的关系相同。 第二个是第一个的实现。

因此，.NET Framework、Xamarin 和 .NET Core 都在其托管框架中为 BCL 实现了 .NET Standard。 由于计算机行业将继续引入新的硬件和操作系统，因此将有新的 .NET 托管框架。 该标准允许应用程序开发人员知道他们可以依赖的一组一致的 API。

每个 .NET 版本都有一个关联的 .NET Standard 版本。

通过提供一致的 API，将应用程序移植到不同的托管实现以及提供工具变得更加容易。

.NET Standard 被定义为单个 NuGet 包，因为需要所有 .NET 实现来支持它。 工具变得更容易，因为这些工具具有用于给定版本的一致 API 集。 您还可以为多个 .NET 实现构建单个库项目。

您还可以为平台特定的 API 构建 .NET Standard 包装器。

Answer 14

每个框架都有自己的类库。

• .Net 框架的基类库。
• .Net 核心的核心库。
• Xamarin 的 Mono 类库。

Microsoft 已决定将所有这些类库整合到一个可在所有框架中实现的库中。 为此，他们开发了 .Net 标准。

微软决定制作一个统一的Framework。 .Net 5 是.Net core 和.Net Framework 的统一框架。 在 .Net 6 中，他们也将 .Net MAUI 项目下的 Xamarin 与 .Net 合并。

.Net Framework、.Net Core、Xamarin 统一到一个单一的Framework .Net 6，所以不需要.Net 标准。 .Net 标准的目标是拥有一个适用于所有框架的库。 现在所有框架都合并到了 .Net 6 中。