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

在创建库时，我们可以将目标设置为。net Standard 2.0，这样所创建的库就可以兼容不同版本的。net Framework，包括。net Core、Mono等等。

简短的回答是:

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 Standard的不同版本

为了让你的应用程序能够在未来实现代码共享和重用，你应该实现。net标准库。

微软还建议您使用. net标准，而不是可移植类库。

引用MSDN作为一个权威的来源，. net标准旨在成为一个库来统治所有的库。由于图片胜过千言万语，下面的内容将使事情变得非常清楚:

1. 您当前的应用程序场景(片断)

和我们大多数人一样，你可能正处于以下情况: (。NET Framework, Xamarin和现在的。NET Core风格的应用程序)

2. .NET标准库将为你提供什么(跨框架兼容性)

实现.NET标准库允许在所有这些不同的风格之间共享代码:

对于没有耐心的人:

.NET Standard solves the code sharing problem for .NET developers across all platforms by bringing all the APIs that you expect and love across the environments that you need: desktop applications, mobile apps & games, and cloud services: .NET Standard is a set of APIs that all .NET platforms have to implement. This unifies the .NET platforms and prevents future fragmentation. .NET Standard 2.0 will be implemented by .NET Framework, .NET Core, and Xamarin. For .NET Core, this will add many of the existing APIs that have been requested. .NET Standard 2.0 includes a compatibility shim for .NET Framework binaries, significantly increasing the set of libraries that you can reference from your .NET Standard libraries. .NET Standard will replace Portable Class Libraries (PCLs) as the tooling story for building multi-platform .NET libraries.

这里有一个表格，可以帮助您了解您可以针对的. net标准的最高版本，以及您打算在哪个. net平台上运行。

来源:MSDN:介绍。net标准

. net和. net Core是. net运行时的两种不同实现。Core和Framework(尤其是Framework)都有不同的配置文件，包括微软为. net创建的许多api和程序集的或大或小(或只是完全不同)的选择，这取决于它们安装在什么配置文件中。

例如，与“普通”Windows配置文件相比，通用Windows应用程序中有一些不同的api。即使在Windows上，你也可能有“Client”配置文件和“Full”配置文件。此外，还有其他实现(如Mono)有自己的库集。

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

A project targeted at a version of Standard will not be able to make use of features that are not included in that revision of the standard. This doesn't mean you can't take dependencies on other assemblies, or APIs published by other vendors (i.e.: items on NuGet). But it does mean that any dependencies you take must also include support for your version of .NET Standard. .NET Standard is evolving quickly, but it's still new enough, and cares enough about some of the smaller runtime profiles, that this limitation can feel stifling. (Note a year and a half later: this is starting to change, and recent .NET Standard versions are much nicer and more full-featured).

另一方面，针对标准的应用程序应该能够在更多的部署情况下使用，因为理论上它可以与Core、Framework、Mono等一起运行。对于一个寻求广泛发行的类库项目来说，这是一个很有吸引力的承诺。对于一个主要面向内部用户的以最终用户为中心的项目，这可能不是一个太大的问题。

. net标准在系统管理员团队想要从ASP。NET在Windows到ASP。出于哲学上或成本上的原因，NET用于Linux上的。NET核心，但开发团队希望继续在Windows上的Visual Studio中使用。NET框架。

前面的回答可能描述了关于。net Core、。net Standard和。net Framework之间区别的最好理解，所以我只想分享一下我在选择这个而不是那个时的经验。

在项目中，你需要混合。net框架，。net核心和。net标准。例如，当我们用。net Core 1.0构建系统时，。net Core还不支持windows服务托管。

第二个原因是我们使用的是不支持。net Core的活动报表。

因此，我们想要构建一个基础架构库，它可以用于。net Core (ASP。NET Core)和Windows服务和报告(。这就是为什么我们选择。NET Standard作为这类库的原因。 选择。net标准意味着你需要仔细考虑库中的每个类都应该是简单的，并且跨越。net(核心、框架和标准)。

结论:

. net标准的基础架构库和共享公共。这个库可以被. net Framework和. net Core引用。 . net框架不支持的技术，如活动报告，窗口服务(现在支持。net 3.0)。 . net核心的ASP。当然是NET Core。

微软刚刚宣布了。net 5:引入。net 5

我希望这将有助于理解。net标准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
    }

}

源