Dotnet Core使用特定的SDK&Runtime版本

前端之家收集整理的这篇文章主要介绍了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版本的规则如下:

  1. 安装了哪个版本的SDK;
  2. global.json定义使用哪个版本的SDK;
  3. 当前SDK版本的前滚策略是什么;
  4. 是否允许使用预发布版本;

我们也依照这些因素来说明这个问题。

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] or update [.\global.json] with an SDK

这个阶段的global.json使用单一版本号,并且不支持通配符。

在一定程序上,这个设置可以解决一些版本方面的问题。但也带来了新的问题。

我们看上面的定义, version 字段的值定义到了版本号的特征版本号和补丁版本号。也就是说,它定义了单一的一个精确版本号。这使得我们不能使用同主副版本的其它任何 SDK 版本,哪怕它是一个更好或更新的版本。

这个问题在 .Net Core 3.0 后有了新的改善。

.Net Core 3.0 后,global.json增加了两个字段:rollForwardallowPrerelease

"2.1.600",
    "allowPrerelease"true,
    "rollForward""patch"
  }
}

在这个设置,有三个参数:

  • version : 设置的特定版本。如果没有设置,将采用安装的最高版本
  • allowPrerelease : 计算使用版本时,是否考虑使用 prereleasepreview的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 版本进行构建和运行。

(全文完)

 


 

@H_590_403@@H_272_404@

微信公众号:老王Plus

扫描二维码,关注个人公众号,可以第一时间得到最新的个人文章内容推送

本文版权归作者所有,转载请保留此声明和原文链接

原文链接:/netcore/993880.html

猜你在找的.NET Core相关文章