无名之路6

C# 的包管理系统，.NET 技术的包管理系统，这是一种全新的包管理系统。既不是 node.js、ruby、python 式的 用一个 npm, gem, pip 就可以搞定(python2有自己的 pip2， python3有自己的pip3)。又不是 java 式的 下载一个 jar 包就完事。

C# 的包管理系统，.NET 技术的包管理系统，这是一种全新的包管理系统 (对标 C++ 的包管理系统)。它既要兼顾不同的 runtime ...... 老兄，python2.7 和 python3.4 已经是不同的 runtime 了 已经出现不兼容的包了，还能怎么兼容？必然是，py2.7 有自己的 pip2 里面的 package 都是 py2.7 能跑的, py3.4 有自己的 pip3 里面的 package 都是 py3.4 能跑的，由 runtime 不同就开始了 package 的泾渭分明。

C# 的包管理系统，.NET 技术的包管理系统，这是一种全新的包管理系统 (对标 C++ 的包管理系统)。
那么，C# 的包管理系统这么复杂，就只有一个原因/目的：

C11 的包 无法在 C99 跑，那么 想用它 怎么办？要么升级到 C11 ，要么 改掉一些运用了C11特性的函数 使之能在 C99 跑。

python3.4 runtime 的包 无法在 python2.7 runtime 跑，那么 想用它 怎么办？要么升级到 python3.4 ，要么 改掉一些运用了python3.4特性的函数 使之能在 python2.7 跑。 (“python 3 已经是另一种语言了”、“pip3 的软件仓库 和 pip2 的软件仓库完全不同”)

.NET Core 3.1 runtime 的包 无法在 .NET Core 2.0 runtime 跑，那么 想用它 怎么办？要么升级到 .NET Core 3.1 ，要么 改掉一些运用了 .NET Core 3.1 特性的函数 使之能在 .NET Core 2.0 runtime 跑，要么 去下载一些它在 .NET Core 2.0 runtime 里(特有的)需要的依赖。
https://www.nuget.org/packages/System.Text.Json

那么，C# 的包管理系统这么复杂，就只有一个原因/目的：
处理历史遗留问题 (.NET 生态太乱，历史悠久) 
处理如何让新版本写的 pacakge 能在老版本 runtime 里运行的问题 

.NET Standard 既然仅仅作为一个标签，还有版本之分，那么 写代码时顾虑它的意义应该不大，就像在写代码的时候，找到一个好用的函数，发现 C99 不支持，C11 支持，那么直接 -std=c11 就 OK 了

观察 “System.Text.Json” 的情况，发现：

• 对于包，只能作 package 化的理解
• 有的包是在标准库中，有的包是没有在标准库中
• 标准库自身也在进步，有可能把一些 package 吸纳到标准库中去
• MS其实是在做一个标准库委员会这种事，和 C99 该支持什么、C11 该支持什么 这样由 C++ 委员会决定的事情是一样的
• 在开发应用时，如果不需要考虑运行环境，可以考虑优先选用最顺眼的技术，然后直接对标到最新的标准库即可；如果需要考虑到适配旧运行环境，再想办法适配旧运行环境
• 在开发应用时，.NET Standard 这种标签是没有什么意义的；在开发 lib 且追求使用新技术时，.NET Standard 这种标签是没有什么意义的，System.Text.Json 直接当作 lib 来直接用 让别人自己去(通过包管理器 nuget)下载依赖去(如果他是 .NET Core 3.1 runtime 那么需要额外下载的依赖最少；如果他是 .NET Core 2.0 runtime 那么需要额外下载的依赖很多啦；如果他是 .NETFramework 4.6.1 runtime 那么需要额外下载的依赖更多啦 1)；在开发 lib 且追求受众广泛时，你应该仅仅使用 .NET Standard 技术，这样 在分发的时候 可以有最广泛的受众 且他们(if any)需要额外下载的依赖最少。

观察 “System.Text.Json” 的情况，发现：

• 最省事的办法：各个版本都对应上 就完事了
• runtime + 软件仓库 + 命令行
• 显式确定 runtime 版本

社区 - .NET Core SDK / runtime 在项目中的版本显式化 

can I install two dotnet - Google 搜索

https://markheath.net/post/switching-between-netcore-sdk-versions

.NET Standard 作为 BCL ，.NET Standard 之外的所有 API 都是 FCL 
https://docs.microsoft.com/zh-cn/dotnet/standard/class-libraries 
https://www.cnblogs.com/makesense/p/6237939.html

微软 作为第三方包的开发者，即 可访问给定平台平台特定的类库 的开发者，它创造了
(下图 深红色部分中除了 BCL 的部分)
.NET Framework runtime 平台
- WPF
- ASP.NET MVC 5 (System.Web) 
- ASP.NET Core MVC
- Web Forms

.NET Core runtime 平台
- WPF (依赖于 Windows 系统)
- ASP.NET Core MVC
- System.Text.JSON

.NET 技术
BCL + FCL，.NET Standard 类库和 第三方库

.NET 类库
=========
https://docs.microsoft.com/zh-cn/dotnet/standard/class-libraries#

有三种类型的类库可供使用：

* 平台特定的类库可访问给定平台（例如，.NET Framework、Xamarin、iOS）中的所有 API，但只有面向该平台的应用和库可使用该类库。
* 可移植类库可访问 API 的子集，并且可供面向多个平台的应用和库使用。
* .NET Standard 类库将平台专用库概念和可移植库概念合并到一个模型中，以同时获取两方面的优势

奇怪的问题

第三方包，到底是一种怎样的发布系统？
为什么这么恐怖？
https://www.nuget.org/packages/System.Text.Json # 这个依赖就非常恐怖 

第三方包，到底是一种怎样的发布系统？
- BCL 和 FCL 它们可以看作 诸多 package 
- 这些 package 如果被贴上了 .NET Standard 的标签，它们就是 BCL 
- System.IO, System.Text 这种 package ，很可能就是 被贴上了 .NET Standard 的标签的，见 doc
- System.Text.JSON 这种 package ，看似应该是也被贴上了 .NET Standard 标签的吧 (否则不会用这种 package 名)？但是 它并没有，见 doc 。但是，它很可能在未来被贴上 .NET Standard (比如 .NS 2.2) 标签
- 这就比较混乱了，你无法准确推断一个 package 是 BCL or FCL (你无法准确判断一个 package 是否来自 Go语言标准库)，那么，最好全都看成 packge 就好了，反正常用的 package 就那么几个。
- 这时候，好用的包管理系统(即使用不到！至少可以声明 它用到了哪些 package )就很重要 

社区 - 聊聊 C# 的包管理系统，.NET 技术的包管理系统，这是一种全新的包管理系统

Go语言标准库 http://codingbefore.com/article/aid/1577071618623 

http://www.cxybcw.com/46828.html 
System.Web 这个类 不是 BCL ，它 在ASP.NET Core 中消失 

https://www.cnblogs.com/makesense/p/6237939.html

https://docs.microsoft.com/en-us/dotnet/api/system.text.json?view=netcore-3.1

https://www.nuget.org/packages/System.Text.Json # 这个依赖就非常恐怖 

奇怪的问题
can I develop ASP.NET Core on .NET framework?

To use .NET technologies not available for .NET Core

ASP.NET Core and the Enterprise: Part 1 Frameworks