Dotnet Core使用特定的SDK&Runtime版本
Dotnet Core的SDK版本总在升级,怎么使用一个特定的版本呢?
假期过完了,心情还在。今天写个短的。
一、前言
写这个是因为昨天刷微软官方文档,发现global.json
在 SDK 3.0 后,更新了一些内容。文档提到了这个更新,但规则说的不太清楚,所以研究了一下,成了这个文章。
先普及一下 .Net Core Runtime 和 .Net Core SDK 的区别,如果请楚,这段可以直接跳过。
我们用命令
% dotnet --list-sdks
查看已安装的Dotnet框架时,会查到类似于下面的内容:
1.1.14 [/usr/local/share/dotnet/sdk]
2.1.600 [/usr/local/share/dotnet/sdk]
2.1.602 [/usr/local/share/dotnet/sdk]
2.1.604 [/usr/local/share/dotnet/sdk]
2.1.700 [/usr/local/share/dotnet/sdk]
2.1.801 [/usr/local/share/dotnet/sdk]
2.2.203 [/usr/local/share/dotnet/sdk]
3.0.100 [/usr/local/share/dotnet/sdk]
3.1.101 [/usr/local/share/dotnet/sdk]
可以看到,我们安装了两类的东西,.Net Core SDK 和 .Net Core Runtime,并且各自对应的版本。其实,SDK 和 Runtime 各有各的用处:
- .Net Core Runtime - 运行时框架。顾名思义,就是
.Net Core
应用运行时需要使用的框架/库。这个框架很小,只能用于运行编译后的代码。也就是说,编译后的程序运行时,会调用这个框架里的库。 - .Net Core SDK - 这个框架很大,是用来做除了运行以外的其它部分:编译、调试应用,以下管理NuGet包等等。当我们开发时,主要用的是这个框架。
所以,在开发机器上我们就需要安装 SDK 和 Runtime 两个框架,而在生产机器上,就仅安装 Runtime 就好了。
同时,SDK 和 Runtime 是对应的,一个特定版本的 SDK,总会对应一个特定版本的 Runtime。
在微软的体系中,.Net Core SDK 是向后兼容的,SDK 3.1 完全可以用来构建 SDK 2.2 类似的应用程序。换句话说,通常不用指定特定版本的SDK来构建应用,用最高的版本就可以。
但是,因为不同的版本,有不同的支持内容,和不同的特性,所以总有些应用是无法兼容的。因此,需要指定特定的 Runtime 版本。
为防止非授权转发,这儿给出本文的原文链接:https://www.cnblogs.com/tiger-wang/p/13811777.html
二、指定特定的SDK版本
前面说了,因为 SDK 向后兼容,通常我们不需要关心安装了哪个版本的 SDK。
但是,总有一些情况会出现:特定版本的BUG、特性变化、项目模板的改变等,导致项目需要某一特定的 SDK 版本。这个时候,我们会用到global.json
。
应用在执行时,dotnet.exe
会在项目目录中查找global.json
文件,并根据global.json
文件的内容来决定使用哪个 SDK 版本来运行应用。当global.json
不存在时,就使用当前最新的 SDK 版本。
按照微软的说法,应用SDK版本的规则如下:
- 安装了哪个版本的SDK;
- global.json定义使用哪个版本的SDK;
- 当前SDK版本的前滚策略是什么;
- 是否允许使用预发布版本;
我们也依照这些因素来说明这个问题。
2.1 检查已安装的版本
在本文开头,给出了一个命令:
% dotnet --list-sdks
这个命令,可以列出已经安装的所有 SDK 及版本号。
微软的版本号会有点复杂,这里举个例子解释一下,2.1.602:
- 最前边的 2,是主版本号;
- 中间的 1,是副版本号;
- 后面的三个数中第一个数是特征版本号,在本例子中,是6;
- 后面三个数中后两个数是补丁版本号,在本例中是02,表示第6个特征版本的第2个补丁。
通常我们在说版本时,一般说到的就是主版本号和副版本号。比方 .Net Core SDK 3.1,就是指主版本为3,副版本为1的版本。
这个版本号,在前滚策略中会很重要。
2.2 global.json
global.json
文件从 .Net Core 1.0就开始引入了。
早期(.Net Core 3.0之前)的内容很简单:
{
"sdk": {
"version": "2.1.600"
}
}
在这个版本中,global.json
文件仅定义了应用使用哪个版本的 SDK。运行时,如果安装对应版本的 SDK,就会正常使用 SDK 并启动。如果不存在对应的 SDK,则会报错:
A compatible installed .NET Core SDK for global.json version [2.1.600] from [.\global.json] was not found
Install the [2.1.600] .NET Core SDK or update [.\global.json] with an installed .NET Core SDK
这个阶段的global.json
使用单一版本号,并且不支持通配符。
在一定程序上,这个设置可以解决一些版本方面的问题。但也带来了新的问题。
我们看上面的定义, version
字段的值定义到了版本号的特征版本号和补丁版本号。也就是说,它定义了单一的一个精确版本号。这使得我们不能使用同主副版本的其它任何 SDK 版本,哪怕它是一个更好或更新的版本。
这个问题在 .Net Core 3.0 后有了新的改善。
.Net Core 3.0 后,global.json
增加了两个字段:rollForward
和allowPrerelease
:
{
"sdk": {
"version": "2.1.600",
"allowPrerelease": true,
"rollForward": "patch"
}
}
在这个设置,有三个参数:
- version : 设置的特定版本。如果没有设置,将采用安装的最高版本
- allowPrerelease : 计算使用版本时,是否考虑使用
prerelease
或preview
的SDK版本 - rollForward : 要应用的前滚策略
这是微软对global.json
参数判断的流程,供参考。
下面,我们重点说一下前滚策略参数。
2.3 前滚策略参数
前滚策略用于确定在请求给定版本时应该选择已安装的 SDK 中的哪一个。通过更改前滚策略,您可以放松或收紧选择条件。这个说法有点抽象,我们举几个例子来说。
在 .Net Core 3.0中,前滚策略有三个类,九个值:
禁用策略:
- disable - 禁用前滚。如果没有确定的版本,就报错。也就是说,不允许使用除指定的版本外的其它任何版本。
保守策略(比禁用要宽松一点):
- patch - 如果版本不存在,就使用相同主、副、特征版本下的最高版本,没有就报错。以上面的例子来说,会使用 2.1.604 版本
- feature - 优先套用 patch 策略;如果不存在,就使用主、次版本相同的下一个特征版本,如 2.1.7xx,没有就报错
- minor - 优先套用 feature 策略;如果不存在,就使用主版本相同的最大版本 2.x.xxx,如本例中的 2.2.203
- major - 优先套用 minor 策略;如果不存在,就使用已安装的最大版本 x.x.xxx,如本例中的3.1.101
最新策略(最宽松的策略):
- latestPatch - 始终使用相同主、副、特征版本下的最高版本 2.1.6xx
- latestFeature - 始终使用相同主、副版本下的最高版本 2.1.xxx
- latestMinor - 始终使用相同主版本下的最高版本 2.x.xxx
- latestMajor - 始终使用已安装的最高版本
出于对 .Net Core 3.0 以前的配置进行兼容,以前的设置会自动采用 latestMajor 设置。
三、总结
一般来说,应用开发中尽可能不要使用global.json
。因为限定了运行时版本,会让生产环境变得复杂。
如果必须使用global.json
,以我的经验,建议指定最低的 SDK 版本,并适当地应用 latestMinor 或 latestFeature 策略。这可能确保项目可以由更多的 SDK 版本进行构建和运行。
(全文完)
微信公众号:老王Plus 扫描二维码,关注个人公众号,可以第一时间得到最新的个人文章和内容推送 本文版权归作者所有,转载请保留此声明和原文链接 |