有時候，我們真想用新框架，可也真不想改代碼。

有一個前置的知識需要了解，就是微軟 Dotnet Core 框架的版本體系。我前邊的文章「Dotnet Core使用特定的SDK&Runtime版本」有詳細(xì)的說明，可以去翻翻看。

前言

有一個舊應(yīng)用，是在 Dotnet Core 2.1 下編譯的服務(wù)端應(yīng)用。本來跑的很好。最近，服務(wù)器上的 Dotnet Core Runtime 框架統(tǒng)一升級到 3.1，于是，這個程序就出問題了。

運(yùn)行時，會報(bào)以下的錯誤：

% dotnet theapp.dll 
It was not possible to find any compatible framework version
The framework 'Microsoft.NETCore.App', version '2.1.0' was not found.
  - The following frameworks were found:
      3.1.11 at [/usr/share/dotnet/shared/Microsoft.NETCore.App]

You can resolve the problem by installing the specified framework and/or SDK.

The specified framework can be found at:
  - https://

為什么會這樣？

這個情況，源于微軟的默認(rèn)框架運(yùn)行規(guī)則：Dotnet Core 應(yīng)用運(yùn)行時，要求運(yùn)行時的版本，主版本號與編譯程序的SDK版本相同，次版本號等于或高于編譯程序的SDK版本。

比方我們上邊這個程序，編譯 SDK 的版本是 2.1.0，因此默認(rèn)可以運(yùn)行在裝有 Dotnet Runtime 2.1.0 - 2.1.28 的所有運(yùn)行時下。?

但是，現(xiàn)實(shí)的情況，我們希望升級框架的主版本。要知道，現(xiàn)在 Dotnet 5.0 已經(jīng)成為常規(guī)版本，6.0 也已經(jīng)到了第五個 Preview 了，升級是必然的。

那么，升級完框架后，如何升級已有的應(yīng)用？

如何升級已有的應(yīng)用？

通常會有這么幾種方式，來升級已有的應(yīng)用：

1. 升級應(yīng)用的編譯 SDK 版本

說白了，就是在指定的新的 SDK 版本下，重新編譯重新生成。

指定特定的 SDK 版本，只需要打開對應(yīng)工程的.csproj文件，在里面加入下面的內(nèi)容：

<PropertyGroup>
  <TargetFramework>netcoreapp3.1</TargetFramework>
</PropertyGroup>

這里面，我們以指定 Dotnet 3.1 為例子。

這兒要注意，5.0 之前，TargetFramework 對應(yīng)的名稱為 netcoreapp，例如 netcoreapp2.1、netcoreapp3.1，而 5.0 之后，微軟把名稱改了，變成了 net5.0、net6.0。?

這個方式，算是幾種方式中，比較麻煩的一種。最基本的前提是，要有工程的源代碼。

如果沒有源代碼，又該怎么辦呢？

2. 顯式覆蓋運(yùn)行時

Dotnet 命令行有一個參數(shù)，可以顯式指定使用特定運(yùn)行時版本來覆蓋編譯版本對應(yīng)的運(yùn)行時。

這個參數(shù)就是 --fx-version。

使用時，命令如下：

% dotnet --fx-version "3.1.11" theapp.dll 

還是上面的例子，這樣一個命令，就可以讓 2.1.0 下編譯的應(yīng)用，在 3.1.11 的運(yùn)行時下運(yùn)行。而這個 3.1.11，就是安裝的運(yùn)行時的版本號。?

如果不知道已安裝的運(yùn)行時的準(zhǔn)確版本號，可以用以下命令查詢：

% dotnet --list-runtimes
Microsoft.AspNetCore.App 3.1.11 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 3.1.11 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

3. 顯式覆蓋 .runtimeconfig.json 文件

這是另一種顯式改變運(yùn)行時的方式。

我們觀察項(xiàng)目的編譯結(jié)果目錄，會看到一個跟隨應(yīng)用的 .runtimeconfig.json 文件。以上面的例子來說，會叫做 theapp.runtimeconfig.json。如果沒有，可以手工創(chuàng)建一個。

看一下它的內(nèi)容：

{
  "runtimeOptions": {
    "tfm": "netcoreapp2.1",
    "framework": {
      "name": "Microsoft.NETCore.App",
      "version": "2.1.0"
    }
  }
}

在這個配置文件中，微軟提供了一個前滾策略，可以通過 rollForward 來定義如果找不到要求的運(yùn)行時版本，程序應(yīng)該如果使用其它版本的運(yùn)行時。

關(guān)于 rollForward 的詳細(xì)說明，在「Dotnet Core使用特定的SDK&Runtime版本」文章中也有詳細(xì)的說明，這兒就不再贅述了。我們直接看內(nèi)容本例的修改內(nèi)容：

{
  "runtimeOptions": {
    "tfm": "netcoreapp2.1",
    "framework": {
      "name": "Microsoft.NETCore.App",
      "version": "2.1.0",
      "rollForward": "major"
    }
  }
}

比較前后兩個文件，只是在中間加了一行："rollForward": "major"，就讓這個程序在高版本的運(yùn)行時下正常運(yùn)行了。

重要的問題

嗯，雖然上面寫了三種方式跨框架運(yùn)行，但是，你一定要注意，跨框架運(yùn)行，不像看上去那么簡單。

你可以去罵微軟。微軟在做 Dotnet 主要版本的升級時，是有破壞性的更改的。也就是說，后面的版本，并不是完全兼容前邊的版本的。某些類或方法，在版本升級時，都可能做了新的設(shè)計(jì)和變更，一些方法會被取消，甚至連所屬的軟件包，都可能發(fā)生變化。

因此，做完上面的工作后，要做仔細(xì)全面的測試。一個應(yīng)用可以工作得很好，不等于每個應(yīng)用都可以。

額外的內(nèi)容：SDK 與 Runtime

在 Dotnet Core 體系中，SDK 與 Runtime 是完全分離的。雖然我們每次安裝時，SDK 與 Runtime 總是一起安裝。

SDK 的版本，僅僅是一個版本號，不同的版本之間，不具有本質(zhì)的區(qū)別。版本號僅僅表示這個 SDK 支持到哪一個版本的內(nèi)容。因此，我們可以從當(dāng)前的 SDK 版本構(gòu)建任何以前的版本，而不僅僅是當(dāng)前安裝的 SDK 版本。

這個話說起來有點(diǎn)繞，舉個例子，我的機(jī)器上只裝了 Dotnet Core 5.0 SDK，我也可以構(gòu)建 Dotnet Core 2.0 的應(yīng)用，而不需要非得裝 Dotnet Core SDK 2.0。

當(dāng)我們 SDK 來構(gòu)建應(yīng)用時，SDK 會根據(jù)構(gòu)建的版本，來下載適當(dāng)?shù)囊冒?。這些包包含構(gòu)建應(yīng)用所需要的占位符、元數(shù)據(jù)和程序集。而編譯系統(tǒng)會根據(jù)這些引用程序集來編譯代碼，以生成應(yīng)用程序。

所以，實(shí)際在開發(fā)環(huán)境中，只需要安裝最新版本的 SDK，就可以了。

運(yùn)行時則不一樣。在早期 Dotnet Framework 系列時，框架是向后兼容的，F(xiàn)ramework 4.5 的框架完全可以運(yùn)行 Framework 2.0 的應(yīng)用程序。但到了 Dotnet Core，就不一樣了，它被明確的版本所定義和區(qū)別。舊版本編譯的程序，在高版本的運(yùn)行時上，不一定能正常運(yùn)行。?

所以，如果你裝了一堆 SDK 和 Runtime，你其實(shí)可以這樣清理：SDK 保留最新的版本，Runtime 保留各個主版本中最新的版本。好在，各個版本僅以目錄的形式存在，清理起來很簡單。

總結(jié)

Dotnet Core 跨框架運(yùn)行是一個很復(fù)雜的內(nèi)容，如果你從頭去翻微軟的文檔，那會很頭大。

因此，我這個文章，用盡量簡單的方式，給大家入個門。