2022/11/8、.NET 7がリリースされて、Visual Studio 2022にも対応する更新17.4.0が降ってきました。ヤッター。
これに伴い、Visual Studioの更新でインストールされている .NET SDKが意図せず変わるのに出会うのが3度を超えたのでメモしておきます。
- 概要
- .NET SDK のリリースと Visual Studio の更新
- .NET の RollForward ポリシーと .NET SDK のバージョン更新
- 新しい .NET SDK のリリースと Visual Studio の更新
概要
- 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の更新がメジャーバージョンだった場合は、入れ替えないで残しておいてほしいお気持ちです。 すべてはそれで解決する...。
