2022/11/8、.NET 7 がリリースされて、Visual Studio 2022 にも対応する更新 17.4.0 が降ってきました。ヤッター。
これに伴い、Visual Studio の更新でインストールされている .NET SDK が意図せず変わるのに出会うのが3度を超えたのでメモしておきます。
- tl;dr;
- .NET SDK のリリースと Visual Studio の更新
- .NET の RollForward ポリシーと .NET SDK のバージョン更新
- 新しい .NET SDK のリリースと Visual Studio の更新
tl;dr;
- Visual Studio 2022 (17.0.0 - 17.3.x) を使って .NET SDK 6.0 をインストールしていると、Visual Studio 2022 (17.4.0) 以降 に更新した際に、.NET SDK 6.0 はアンインストールされて .NET SDK 7.0 のみになります
- Visual Studio に依存せずに 特定の .NET SDK を維持したい場合は、winget や インストーラーを使って .NET SDK をインストールしておきましょう。(そして .NET SDK の更新どうする問題に出会う)
.NET SDK のリリースと Visual Studio の更新
Visual Studio を使って .NET SDK をインストールしている人は多いかと思います。この仕組みはいろいろ便利な側面があります。
- Visual Studio 2017 以降、.NET SDK は Visual Studio を使用してインストールできるようになりました。(Visual Studio Installer でインストールする .NET SDK のこと)
- 新しい .NET のバージョンがリリースされると、.NET SDK や .NET Runtime、そして Visual Studio にも更新が降ってきます
- Visual Studio を使用して .NET SDK をインストールしている場合、新しい .NET SDK への更新を伴う Visual Studio へ更新するとインストールされている .NET SDK が新しいものに差し変わります
Visual Studio の更新をするだけで.NET SDK も更新できる、これは Visual Studio を使って書いている人には非常に便利な仕組みです。
この仕組みが生きた直近の例として、.NET SDK 6.0.2 にはビルドで困るバグがありました、が、Visual Studio を更新しているだけでバグが解消された .NET SDK 6.0.3 を利用できるようになりました。 多分何が困ったのか気づかなかった方も多かったのではないかと思います。いい仕組みですね。
Visual Studio を更新していくだけで最新の .NET SDK が利用できる、最高ですね！
.NET の RollForward ポリシーと .NET SDK のバージョン更新
なぜ Visual Studio による .NET SDK の更新で普段困っていないかというと、「RollForward ポリシーはlatestPatch」と 「.NET SDK の更新がパッチレベルである」と「TargetFramework の指定はマイナーレベル」の3者が合致しているため、なんの不自由もなく利用できるわけです。
- .NET のアプリケーションは RollForward ポリシーという仕組みで異なる .NET SDK でも latestPatch 1 で解決できる限りは互換性があると認識して動作します。2
- Visual Studio 17 (17.0.0 ～ 17.3.x) の間にあった .NET SDK のバージョン更新は 6.0.0 ～ 6.0.x とパッチレベルでした
- csproj の TargetFramework は net6.0 や net7.0 とマイナーバージョンレベルの指定
パッチレベルの更新なので、副作用も考える必要がない3 ということもあり実際開発環境の更新をあまり意識せずに済んでいるでしょう。
仮に .NET SDK が 2.1 から 2.2 とマイナーバージョン更新されると、困るわけですね。(.NET の RollForward は .NET Core 3.1 からの紹介なので影響なかったですが)
同様に、RollForward を latestPatch ではなく、 patch と厳密に指定しても Visual Studio の更新で .NET SDK のパッチレベル更新が入ったときに困ることになります。
If no rollForward value is set, it uses
latestPatchas the default rollForward policy. Otherwise, check each value and their behavior in the rollForward section.
RollForward は実行時のランタイム指定なので、Visual Studio でビルドしてデバッグ実行する際はビルドしなおしているので困らないというのもあります。
このことを踏まえて、今回の .NET 7 のリリースを見てみましょう。
新しい .NET SDK のリリースと Visual Studio の更新
今回は、.NET 7 の GA に伴い、Visual Studio 2022 (17.4.0) の更新が配布されました。 従来の Visual Studio による .NET SDK の更新と違うのは、メジャーバージョンの更新 (.NET SDK 6.0 から .NET SDK 7.0) だったということです。
結果起こったのは、更新前は .NET SDK 6.0 がインストールされていたのに、VS2022 (17.4.0) に更新したら .NET SDK 7.0 のみになってビルドや実行で困るようになったのでした。 csproj での TargetFramework レベルで一致しないので、メジャーレベルの .NET SDK 6.0 が Visual Studio の更新で消えるのは影響高いのです。
ということで、こういうのに困る場合はいずれかがいいのですかねぇ。
- プロジェクトで必要な .NET SDK は Visual Studio とは別でインストーラーやwinget でインストールしておく。(安パイ。.NET SDK の更新はwingetやscoopじゃないと困りますね)
- Visual Studio の更新に合わせてTargetFramework も新しい.NET バージョンに更新する。(アグレッシブですね。更新タイミング揃える努力がそこそこ必要)
- 先に Visual Studio Preview で 次の .NET SDK が rc リリース時点から TargetFramework を上げる。(チャレンジャーと言わざるを得ないが以外と安パイ)
個人的には、Visual Studio による .NET SDK の更新がメジャーバージョンだった場合は、入れ替えないで残しておいてほしいお気持ちです。 すべてはそれで解決する...。
