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


What is the difference between .NET Core and .NET Standard Class Library project types?

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

  • 类库(.NET框架)
  • 类库(.NET标准)
  • 类库(.NET核心)

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

那么，类库(.NET标准)和类库(.NET核心)之间有什么区别，为什么两者都存在，以及我们什么时候应该使用它们？

相关讨论

When should we use one over the other?

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

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

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

例如，面向.NET标准1.3的库将与面向.NET Framework 4.6、.NET Core 1.0、通用Windows平台10.0和任何其他支持.NET标准1.3的平台的应用程序兼容。不过，库将无法访问.NET API的某些部分。例如，Microsoft.NETCore.CoreCLR包与.NET核心兼容，但与.NET标准不兼容。

What is the difference between Class Library (.NET Standard) and Class Library (.NET Core)?

基于包的框架部分描述了区别。

兼容性：以.NET标准为目标的库将在任何符合.NET标准的运行时上运行，如.NET核心.NET框架、mono/xamarin。另一方面，面向.NET核心的库只能在.NET核心运行时上运行。

API表面积：.NET标准库附带了NETStandard.Library中的所有内容，.NET核心库附带了Microsoft.NETCore.App中的所有内容。后者包括大约20个附加库，其中一些库可以手动添加到.NET标准库(如System.Threading.Thread)中，有些库与.NET标准不兼容(如Microsoft.NETCore.CoreCLR)。

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

Why do both exist?

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

回到库中，.NET标准库模板可以在多个运行时运行(以牺牲API表面积为代价)。显然，.NET核心库模板的存在是为了访问更多的API表面积(以牺牲兼容性为代价)，并指定一个用于构建可执行文件的平台。

相关讨论

.NET核心类库是基于.NET标准构建的。如果要实现可移植到.NET框架、.NET核心和Xamarin的库，请选择.NET标准库。

.NET核心最终将实现.NET标准2(Xamarin和.NET框架也是如此)

因此，可以将.NET核心、Xamarin和.NET框架标识为.NET标准的味道。

为了将来证明您的应用程序可以共享和重用代码，您宁愿实现.NET标准库。

Microsoft还建议您使用.NET标准而不是可移植类库。

为了引用msdn作为权威源，.net标准旨在成为一个库来管理它们。由于图片价值千言万语，以下内容将使事情变得非常清楚：

1。您当前的应用程序场景(碎片化)

像我们大多数人一样，您可能处于以下情况：(.NET框架、Xamarin和现在的.NET核心应用程序)

enter image description here

2。.NET标准库将为您启用什么(跨框架兼容性)

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

One Library to Rule them All

对于不耐烦的人：

  • .NET标准通过在您需要的环境中引入您期望和喜爱的所有API来解决所有平台上的.NET开发人员的代码共享问题：桌面应用程序、移动应用程序和游戏以及云服务：
  • .NET标准是所有.NET平台都必须实现的一组API。这将统一.NET平台并防止将来的碎片化。
  • .NET标准2.0将由.NET框架.NET核心.和XAMARIN。对于.NET核心，这将添加许多现有的API已经请求了。
  • .NET Standard 2.0包含.NET框架二进制文件的兼容性填充程序，显著增加了可以从.NET标准库引用的库集。
  • .NET标准将替换可移植类库(PCL)作为用于构建多平台.NET库的工具故事。

    • 为了让一个表帮助理解您可以针对的.NET标准的最高版本是什么，基于您打算在哪个.NET平台上运行，请访问这里。

    来源：msdn:介绍.NET标准

    相关讨论

    因此，短的答案是：

    1
    2
    3
    IAnimal == .NetStandard (General)
    ICat == .NetCore (Less General)
    IDog == .NetFramework (Specific / oldest and has the most features)
    相关讨论

    NET框架和。NET的核心是两种不同的实现的.NET运行库。这两个核心和框架(但可以有不同的配置文件的框架)，包括较大的或较小的(或只是平原的许多不同的选择)和组件的API创建的微软。NET，取决于他们是什么和在哪里安装配置文件。例如，有一些不同的可用的应用程序在Windows API的通用比"正常"的Windows配置文件。即使在Windows中，你可以有"客户"与"全"的剖面分布。此外，还有其他的实现(样单)有自己的一套库。

    NET是一个规范的标准。这套API的库和组件必须是可用的。对应用程序写的。NET 1.0标准应该可以编译和运行任何版本的框架，核心，单等，这是标准的趋势支持.NET 1.0的收藏库。类似的是为标准的。NET 1.1，1.5，1.6，2.0等，只要在提供支持的运行时版本的标准靶向的程序，你的程序应该运行那里。

    在一个版本的项目有针对性的标准，不可以让使用的功能是不包括在这一修改的标准。这并不意味着你不能把对其他组件的依赖关系，或由其他供应商的原料药(如：发表在nuget项目)。但它并不意味着你必须所以不包含任何依赖关系的版本的支持。网络标准。标准是不断变化的。网最新，但它的安静和关心不够，不够，一些更小的运行配置文件的限制，这是stifling CAN的感觉。(注：一年半后，这是从最近的变化，和。NET版本更好和更多的标准是全功能)。

    在其他的手，你可以在标准靶向应用程序中使用更多的部署情况，因为它可以运行在一个理论框架，单核，一个类库项目等的宽分布，这是一个有吸引力的承诺。一个类库项目主要是用于内部目的，它可能需要的是A多的关注。

    NET可以使用标准的情况下，想在sysadmin团队是移动从ASP.NET在Windows和ASP.NET。.NET在Linux核心的哲学或成本的原因，但对开发团队想要继续工作在Visual Studio。NET框架在Windows中。

    相关讨论

    .NET框架和.NET核心都是框架。

    .NET标准是标准的(换句话说，规范)。

    您可以使用.NET框架和.NET核心生成可执行项目(如控制台应用程序或ASP.NET应用程序)，但不能使用.NET标准。

    使用.NET标准，您只能创建不能独立执行的类库项目，并且应被其他.NET核心或.NET框架可执行项目引用。

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

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    68
    69
    70
    71
    72
    73
    74
    75
    76
    77
    78
    79
    80
    81
    82
    83
    84
    85
    86
    87
    88
    89
    90
    91
    92
    93
    94
    95
    96
    97
    98
    99
    100
    101
    102
    103
    104
    105
    106
    107
    108
    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
    }
    }

    来源

    .NET标准：把它看作一个大的标准库。将此项用作依赖项时，只能生成库(.dlls)，不能生成可执行文件。以.NET标准作为依赖项的库可以添加到xamarin.android、xamarin.ios、.NET核心windows/osx/linux项目中。

    .NET核心：把它看作是旧.NET框架的延续，只是它是开放源码，有些东西还没有实现，有些则被否决了。它用额外的功能扩展了.NET标准，但只在桌面上运行。当将其作为依赖项添加时，您可以在Windows、Linux和OSX上创建可运行的应用程序。(尽管控制台只是暂时的，没有GUI)。所以.NET核心=.NET标准+特定于桌面的东西。另外，uwp使用它，新的ASP.NET核心也使用它作为依赖项。

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

    因此，使用.NET框架，您可以使用所有.NET工具，但只能针对Windows应用程序(UWP、WinForms、ASP.NET等)。因为.NET框架是封闭源代码的，所以没有什么可做的。

    有了.NET核心，你的工具就更少了，但是你可以瞄准主要的桌面平台(Windows、Linux、Mac)。这在ASP.NET核心应用程序中特别有用，因为您现在可以在Linux中托管ASP.NET(更低的托管价格)。现在，由于.NET核心是开源的，所以从技术上讲，它可以为其他平台开发库。但由于没有支持它的框架，我认为这不是一个好主意。

    使用.NET标准，您的工具甚至更少，但您可以瞄准所有/大多数平台。由于Xamarin的存在，你可以瞄准手机，而Mono/Unity甚至可以瞄准游戏机。

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

    服务器和客户端共享：

    • 处理应用程序模型的.NET标准库。

    因为它是.NET标准库，所以可以在任何其他库中使用。

    服务器端(Web API)：

    • 一个.NET标准(也可以是核心)库，它处理所有数据库连接。

    • 一个.NET核心项目，它处理REST API并使用数据库库。

    由于这是在.NET核心中开发的，所以我可以在Linux服务器上托管应用程序。

    客户端(带wpf+xamarin.forms android/ios的MVVM)：

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

    • 处理ViewModels逻辑的.NET标准库。用于所有的观点。

    • 一个.NET框架WPF应用程序，用于处理Windows应用程序。

    • 处理Xamarin窗体视图的.NET标准库。

    • Xamarin Android和Xamarin iOS项目。

    因此，您可以看到，在应用程序的客户端有一个很大的优势，因为我可以重用.NET标准库(客户机API和ViewModels)，并且只生成对WPF、Xamarin和IOS应用程序没有逻辑的视图。

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

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

    .NET标准是.NET API的正式规范，旨在在所有.NET实现上都可用。

    .NET核心是一个免费的开放源码管理计算机软件框架，适用于Windows、Linux和MacOS操作系统。

    .NET框架是主要在Microsoft Windows上运行的软件框架。