• 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] .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增加了两个字段:rollForwardallowPrerelease

    {
      "sdk": {
        "version""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 版本进行构建和运行。

    (全文完)


    微信公众号:老王Plus

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

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

  • 相关阅读:
    linux下Boost序列化问题解决
    树莓派搭建基于flask的web服务器-通过移动端控制LED
    unison+inotify
    员工为什么会离职 (转)
    编译安装 Centos 7 x64 + tengine.2.0.3 (实测+笔记)
    Cassandra 原理介绍
    使用Go语言编写区块链P2P网络(译)(转)
    缓存击穿举例
    Cassandra 原理介绍
    Go学习之路
  • 原文地址:https://www.cnblogs.com/tiger-wang/p/13811777.html
Copyright © 2020-2023  润新知