.NET Standard vs. .NET Core
What is the difference between .NET Core and .NET Standard Class Library project types?
Answer1
When should we use one over the other?
The decision is a trade-off between compatibility and API access.
Use a .NET Standard library when you want to increase the number of apps that will be compatible with your library, and you are okay with a decrease in the .NET API surface area your library can access.
Use a .NET Core library when you want to increase the .NET API surface area your library can access, and you are okay with allowing only .NET Core apps to be compatible with your library.
For example, a library that targets .NET Standard 1.3 will be compatible with apps that target .NET Framework 4.6, .NET Core 1.0, Universal Windows Platform 10.0, and any other platform that supports .NET Standard 1.3. The library will not have access to some parts of the .NET API, though. For instance, the Microsoft.NETCore.CoreCLR
package is compatible with .NET Core but not with .NET Standard.
What is the difference between Class Library (.NET Standard) and Class Library (.NET Core)?
The Package-based frameworks section describes the difference.
Compatibility: Libraries that target .NET Standard will run on any .NET Standard compliant runtime, such as .NET Core, .NET Framework, Mono/Xamarin. On the other hand, libraries that target .NET Core can only run on the .NET Core runtime.
API Surface Area: .NET Standard libraries come with everything in NETStandard.Library
whereas .NET Core libraries come with everything in Microsoft.NETCore.App
. The latter includes approximately 20 additional libraries, some of which we can add manually to our .NET Standard library (such as System.Threading.Thread
) and some of which are not compatible with the .NET Standard (such as Microsoft.NETCore.CoreCLR
).
Also, .NET Core libraries specify a runtime and come with an application model. That's important, for instance, to make unit test class libraries runnable.
Why do both exist?
Ignoring libraries for a moment, the reason that .NET Standard exists is for portability; it defines a set of APIs that .NET platforms agree to implement. Any platform that implements a .NET Standard is compatible with libraries that target that .NET Standard. One of those compatible platforms is .NET Core.
Coming back to libraries, the .NET Standard library templates exist to run on multiple runtimes (at the expense of API surface area). Obversely, the .NET Core library templates exist to access more API surface area (at the expense of compatibility) and to specify a platform against which to build an executable.
Answer2
A .Net Core Class Library is built upon the .Net Standard. If you want to implement a library that is portable to the .Net Framework, .Net Core and Xamarin, choose a .Net Standard Library
.Net Core will ultimately implement .Net Standard 2 (as will Xamarin and .Net Framework)
.Net Core, Xamarin and .Net Framework can, therefore, be identified as flavours of .Net Standard
To future-proof your applications for code sharing and reuse , you would rather implement .Net Standard libraries.
Microsoft also recommends that you use .NET Standard instead of Portable Class Libraries.
To quote MSDN as an authoritative source, .Net Standard is intended to be One Library to Rule Them All. As pictures are worth a thousand words, the following will make things very clear:
1. Your current application scenario (fragmented)
Like most of us, you are probably in the situation below: (.Net Framework, Xamarin and now .Net Core flavoured applications)
2. What the .Net Standard Library will enable for you (cross-framework compatibility)
Implementing a .Net Standard Library allows code sharing across all these different flavours:
For the impatient:
- .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.
For a table to help understand what the highest version of .NET Standard that you can target, based on which .NET platforms you intend to run on, head over here.
Sources: MSDN: Introducing .Net Standard
.NET Standard vs. .NET Core
In Visual Studio, there are at least 3 different types of class library you can create:
- Class Library (.NET Framework)
- Class Library (.NET Standard)
- Class Library (.NET Core)
* Use a .NET Standard library when you want to increase the number of apps that will be compatible with your library, and you are okay with a decrease in the .NET API surface area your library can access.
* Use a .NET Core library when you want to increase the .NET API surface area your library can access, and you are okay with allowing only .NET Core apps to be compatible with your library.
Difference:
Compatibility: Libraries that target .NET Standard will run on any .NET Standard compliant runtime, such as .NET Core, .NET Framework, Mono/Xamarin. On the other hand, libraries that target .NET Core can only run on the .NET Core runtime.
API Surface Area: .NET Standard libraries come with everything in NETStandard.Library
whereas .NET Core libraries come with everything in Microsoft.NETCore.App
. The latter includes approximately 20 additional libraries, some of which we can add manually to our .NET Standard library (such as System.Threading.Thread
) and some of which are not compatible with the .NET Standard (such as Microsoft.NETCore.CoreCLR
).
Also, .NET Core libraries specify a runtime and come with an application model. That's important, for instance, to make unit test class libraries runnable.
Ignoring libraries for a moment, the reason that .NET Standard exists is for portability; it defines a set of APIs that .NET platforms agree to implement. Any platform that implements a .NET Standard is compatible with libraries that target that .NET Standard. One of those compatible platforms is .NET Core.
Coming back to libraries, the .NET Standard library templates exist to run on multiple runtimes (at the expense of API surface area). Obversely, the .NET Core library templates exist to access more API surface area (at the expense of compatibility) and to specify a platform against which to build an executable.
Said another way…
A .Net Core Class Library is built upon the .Net Standard. If you want to implement a library that is portable to the .Net Framework, .Net Core and Xamarin, choose a .Net Standard Library
.Net Core will ultimately implement .Net Standard 2 (as will Xamarin and .Net Framework)
.Net Core, Xamarin and .Net Framework can, therefore, be identified as flavours of .Net Standard
To future-proof your applications for code sharing and reuse , you would rather implement .Net Standard libraries.
Microsoft also recommends that you use .NET Standard instead of Portable Class Libraries.
To quote MSDN as an authoritative source, .Net Standard is intended to be One Library to Rule Them All.
- .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.
References: https://blogs.msdn.microsoft.com/dotnet/2016/09/26/introducing-net-standard/
https://stackoverflow.com/questions/42939454/what-is-the-difference-between-net-core-and-net-standard-class-library-project
.NET Standard vs. .NET Core的更多相关文章
- 错误处理:java.lang.NoClassDefFoundError: org/apache/taglibs/standard/tag/rt/core/ForEachTag
在使用JSP.Servlet进行开发时,遇到java.lang.NoClassDefFoundError: org/apache/taglibs/standard/tag/rt/core/ForEac ...
- .NET Standard和.NET Core是什么关系(转载)
.NET Standard vs .NET Core 问: I have read about the difference between .NET Standard and .NET Core, ...
- .NET Standard - 揭秘 .NET Core 和 .NET Standard[转自MSDN]
作为 .NET 系列的最新成员,.NET Core 和 .NET Standard 的概念及其与 .NET Framework 的区别并不十分明确.在本文中,我将准确介绍每个产品及其适用场景. 在详细 ...
- .Net Standard(.Net Core)实现获取配置信息
一.前言 在.Net Framework框架有专门获取webconfig配置的方法供我们使用,但是在.Net Core或者.Net Standard中没有可以直接使用的方法来获取配置文件信息,下面就来 ...
- The tag handler class for "c:set"(org.apache.taglibs.standard.tag.rt.core.UrlTag)was not found on the Java Build Path
1.源码: <%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %> < ...
- The tag handler class for "c:forEach" (org.apache.taglibs.standard.tag.rt.core.ForEachTag) was not found on the Java Build Path
.tag出现如上错误 <%@ page language="java" contentType="text/html; charset=GB18030" ...
- The tag handler class for "home.jsp" (org.apache.taglibs.standard.tag.rt.core.ForEachTag) was not found on the Java Build Path
web.xml中 listener,filter,servlet需按顺序. <listener> <listener-class>listener.VisitCountList ...
- 将 Net 项目升级 Core项目经验:(一)迁移Net项目为Net Core\Standard项目
迁移Net项目为Net Core\Standard项目 背景: 我们公司内部有自己ORM开发框架,最新因为需要将系统迁移到国产服务器上,所以首先需要将最基础的ORM框架改造可以运行在国产服务器上.对于 ...
- 一篇很好的解释了.Net Core, .Net Framework, .Net standard library, Xamarin 之间关系的文章 (转载)
Introducing .NET Standard In my last post, I talked about how we want to make porting to .NET Core e ...
随机推荐
- 十二 总结JS原型
基本概念: 对象:属性和方法的集合(变量和函数的封装). 构造器函数:用于创建对象的函数,通过new关键字生成对象.函数名一般首字母大写的. 原型对象:每个函数都有一个prototype属性,它是一个 ...
- Shader2.0常用语义
POSITION: 获取模型顶点的信息.NORMAL: 获取法线信息TEXCOORD(n): 高精度的从顶点传递信息到片段着色器COLOR: 表示低精度从顶点传递信息到片段着色器 ...
- Big Event in HDU (母函数, 玄学AC)
Nowadays, we all know that Computer College is the biggest department in HDU. But, maybe you don't k ...
- 集合List
//数组 存值长度固定,类型固定 //集合 长度不固定,类型也可以不固定 List<int> list = new List<int>(); //list.Add(78); ; ...
- Java volatile详解
转自:http://www.cnblogs.com/dolphin0520/p/3920373.html volatile这个关键字可能很多朋友都听说过,或许也都用过.在Java 5之前,它是一个备受 ...
- JAVA中获取文件MD5值的方法
1 DigestUtils.md5Hex(new FileInputStream(path)); 如果你只需要使用标准的MD5,其实一行代码就够了,JAVA自带的commons-codec包就提供了获 ...
- flask 处理表单数据
处理表单数据 表单数据的处理涉及很多内容,从获取数据到保存数据大致有以下步骤: 1. 解析请求,获取表单数据 2. 对数据进行必要的转换,比如讲勾选框的值转换成python的布尔值 3. 验证数 ...
- 转:【专题七】UDP编程补充——UDP广播程序的实现
上次因为时间的关系,所以把上一个专题遗留下的一个问题在本专题中和大家分享下,本专题主要介绍下如何实现UDP广播的程序,下面就直接介绍实现过程和代码以及运行的结果. 一.程序实现 UDP广播程序的实现代 ...
- 文件缓冲区在fork后复制
场景:父进程trace进程A,当A进程fork子进程B时,让父进程也fork子进程去trace子进程B,用于trace的进程将被trace的进程发生的系统调用号通过fprintf存入各自文件中 问题: ...
- nvidia-docker
参考资料 https://github.com/NVIDIA/nvidia-docker/wiki/Installation#prerequisites https://github.com/NVID ...