这几天（9月26日-30日)微软ignite 2016（去年起由 ignite 取代 TechEd）正在美国如火如荼的召开，乍见一个新名词：.nET standard 2.0。 我得了一种听到新名词就会焦虑的病，赶紧查数据压压惊…

　　.nET Team Blog 同步发布了一篇教程文，可说是目前最全面最权威的数据源，抱着懂个大概就好的心态，整理重点如下。

　　先用两张图说明为何没事要搞出一套 .nET standard 新标准？ （注：图片取自 Msdn Blog 文章）

　　.nET standard 的核心使命在于处理 .nET 跨平台时基础链接库不一致的问题。.nET 发展至今，已初步实现跨平台， 用 C# 就可以写 win、macos、Linux、ios、Android 程序。 但如下图所示，.nET Framework BCL、.nET Core Library 与 xamarin 的 Mono Class Library 各自发展，缺乏统一的界面标准，像是system.Collections, system.io, system.xml… 这类性质的基础类别，各家支持程度不一，某些 Api 可能在某个平台不存在，又或者 Api 界面存在差异。

　　如果您只专注一种平台，当然可以无视各平台基础链接库的差异，专心学好一种就好。 但如果系统被要求跨平台，差异那怕再小，都会跑出来咬您屁股。 首先，您必须搞懂不同平台的差异，第二，差异提高“跨平台共同链接库/组件”开发的难度。 （脑海中出现一堆恶心的 #if nETCoRE … #elif xAMARin … #endif） 。

　　过去针对跨平台分享链接库的主推做法是pCL（portable Class Library），取多个平台的交集，筛选保留各平台都支持的 Api，但开发者仍需了解不同平台的差异。.nET standard 则试图规范一套标准基础链接库 Api 界面，各平台依此界面实作出一致的链接库，如此程序代码不需修改即可针对不同平台编译、执行。

　　即使有 .nET standard，还是无法逃避各平台支持度不一的现况。.nET standard 版本号码与 Api 全能度成正比，与支持平台范广度成反比。.nET standard 2.0提供的 Api 数目一定比 1.0 多，但如果想涵盖 win phone 8，就只能选择 .nET standard 1.0 – 1.2。 dotnetstd-2

　　随着 .nET standard 2.0 制定，.nET Core 与 xamarin 将在新版加入支持，而 .nET Framework 4.6.1 则已符合 2.0 标准。 有没有注意上表的玄机？.nET standard 1.4 对应到 .nET Framework 4.6.1、1.5 对 4.6.2，后果 2.0 又倒车回到 4.6.1，原来是基于部署普及率考虑，.nET standard 2.0 拿掉 1.5/1.6 增加但应用不广的 Api，好让 .nET Framework 4.6.1 符合 .nET standard 2.0。 各位同学，今天你们要教程的成语是－“削足适履”～（笑 ）

　　以下是 .nET standard 2.0 的主要涵盖范围，细节则参考 github 上的文件。 .nET standard 2.0 仍在发展中，未来可能还会有变动。

　　至于一些与平台高度关于的 Api，例如：只有 win 才有的 Registry、Reflection Emit 功能不适用 .nET native、uwp、xamarin ios。.nET standard 采取“需额外安装 nuGet package 才能使用，在不适用平台执行时抛出例外”的原则，不同的 Api 解决方式不一。

　　如果您需要开发跨平台链接库，绿色建议改走 .nET standard，以降低平台相依性，并允许混合参照 pCL 及 .nET Framework，但 pCL 仍适用特定场合，例如：某些平台不在 .nET standard 支持之列，pCL 是唯一解。 实作上有个 Api port可侦测程序适用的最低 .nET standard 标准，再配合检查目标平台是否在该标准支持范围，以便决定标准版本。

　　全能的 .nET standard 工具支持将内置于下一版本 Visual studio “dev 15′，以 nuGet package 方式加入参照，而未来 Visual studio、VsCode、xamarin studio 均会提供一线支持。