.NET 11 Preview 3：開発者のレビュー

C# 15聯合型: 大きなもの

もしOneOf<T1, T2>ライブラリを作成していたり、封印されたレコード階層を手作りしていたり、単にF#開発者を羨んでいたりするならば、これは見逃せません。C# 15は、固定されたタイプ集合の一つであることを宣言するためのunionキーワードを導入します。コンパイラによって完全性が保証されます。 聯合型はプレビュー2で登場しました; プレビュー3はそれに関連するIDEサポートを磨きました。

C#チームのアプローチは、F#の判別聯合よりも聯合型に近い: メンバー型はあなたが別に定義した既存の型であり、聯合宣言内にネストされたタグケースではありません。 聯合は本質的に、オブジェクトを包み込み、それに入るものを制限する構造体です。 呼び出しサイトからはネイティブに感じられます。メンバータイプからユニオンへの暗黙の変換、Pet.Value上での完全なswitch式、そしてコンパイラがすべてのケースを把握している場合にはデフォルトの枝が不要です。

[Union]
public partial struct Pet : IUnion
{
    public Pet(Dog dog);
    public Pet(Cat cat);
    public Pet(Bird bird);
}

string Describe(Pet pet) => pet.Value switch
{
    Dog d  => $"Dog named {d.Name}",
    Cat c  => $"Cat ({c.Color})",
    Bird b => $"Bird, {b.Species}",
    // no default - compiler knows the set is closed
};

[Union]
public partial struct Pet : IUnion
{
    public Pet(Dog dog);
    public Pet(Cat cat);
    public Pet(Bird bird);
}

string Describe(Pet pet) => pet.Value switch
{
    Dog d  => $"Dog named {d.Name}",
    Cat c  => $"Cat ({c.Color})",
    Bird b => $"Bird, {b.Species}",
    // no default - compiler knows the set is closed
};

<Union>
Public Partial Structure Pet
    Implements IUnion

    Public Sub New(dog As Dog)
    End Sub

    Public Sub New(cat As Cat)
    End Sub

    Public Sub New(bird As Bird)
    End Sub
End Structure

Function Describe(pet As Pet) As String
    Return pet.Value Select Case
        Case d As Dog
            Return $"Dog named {d.Name}"
        Case c As Cat
            Return $"Cat ({c.Color})"
        Case b As Bird
            Return $"Bird, {b.Species}"
        ' no default - compiler knows the set is closed
    End Select
End Function

利点は明確です。閉じたタイプ、無効な状態なし、NotImplementedExceptionat午前3時ではなくコンパイル時に読み切ることができます。 ペットを聯合に追加し、それに対するすべてのスイッチが警告を点灯し、あなたがそれを処理するまで。

短所も実であり、誠実なレビューでフラグを立てる価値があります。 公開されたオブジェクト値のプロパティが臭い - タイプセーフなものの背後に隠していることについてGitHubでの公開討論があります。 公のコンストラクターは、聯合が受け入れる型を暗に定義しているが、それは発見可能でも明示的でもありません。 F#の相互運用性は未解決です（2つのモデルは根本的に異なります）。 そして、より広範な包括性の物語にはまだギャップがあります: 閉じた階層と閉じた列挙型、完全な絵を完成させる2つの提案は、まだ提案です。 聯合だけでも素晴らしいですね。 聯合と閉じた列挙型と閉じた階層とがあれば、それは世代交代のシフトとなるでしょう。 私たちはそこにまで到達していません。

Runtime Async V2およびJITの改善

Runtime Asyncは、非同期/待機が実際にどのように実行されるかについて for .NETの静かな書き換えです。 C#コンパイラーが非同期メソッドごとに状態マシンのクラスを発行する代わりに、ランタイム自体が中断と再開を管理します。 目に見える成果: クリーンなスタックトレース、小さい割り当て、そしてMoveNextフレームをスクロールして自分のコードを見つけなくてもいいデバッガー。

プレビュー3では、ランタイム非同期がEnablePreviewFeatures要件を削除します。 依然として機能スイッチを切り替える必要があります - <Features>runtime-async=on</Features> - しかし、もはやすべてのAPIコールをプレビュー領域に切り替える必要はありません。 また、このプレビューではNativeAOTとReadyToRunのサポートも追加されており、JITとAOTのシナリオ間のギャップを埋めます。 継続オブジェクトがより積極的に再利用され、変更されていないローカルは中断後にも保存されません。 非同期が頻繁に使用されるコードパス - 例えば、KestrelパイプラインやEF Coreクエリワーカー - では、割り当ての圧力が実質的に減少します。

JITは、"既存のコードが今はより速い、何もする必要はない"ということ新しいバッチを取得しました:

• xが0または1または2または3または4のようなマルチターゲットスイッチ式は、分岐なしチェックに統合されます。
• 値[^1] + 値[^2] パターンに対する境界チェックがより積極的に除去され、ループ内の一般的な i + cns < len ケースが綺麗に解消されます。
• 符号なし int から float や符号なし int から double へのキャストが、AVX-512 より前の x86 ハードウェアで高速化されます - これはニッチですが、古いマシンを使っている場合には現実的です。

WebAssemblyユーザーは、WebCILペイロードのランタイム内での直接ロード、より良いデバッグシンボル、および往復オーバーヘッドなしのfloat[] / Span<float> / ArraySegment<float>のマーシャリングを利用できます。 これらのどれも個別には劇的ではありませんが、Blazor WASM を妥協と感じさせないようにするための積み重ね作業です。

問題はハードウェアの下限です。 .NET 11 は x86/x64 と Arm64 の最小命令セット要件を引き上げます。Apple Silicon とほとんどの Linux SBC は問題ありません - Arm64 の ReadyToRun ターゲットは LSE を追加するだけですが、非常に古い x86 ハードウェアは除外されます。 インプレースアップグレードを想定する前に、フリートを監査してください。

ASP.NET Core と Blazor

Zstandardはここのヘッドライナーです。 ASP.NET Core は、レスポンス圧縮とリクエスト解凍の両方で zstd をサポートし、ミドルウェアを追加するとデフォルトで有効になります。 設定は予想される形状と同じです:

builder.Services.AddResponseCompression();
builder.Services.AddRequestDecompression();
builder.Services.Configure<ZstandardCompressionProviderOptions>(options =>
{
    options.CompressionOptions = new ZstandardCompressionOptions { Quality = 6 };
});

builder.Services.AddResponseCompression();
builder.Services.AddRequestDecompression();
builder.Services.Configure<ZstandardCompressionProviderOptions>(options =>
{
    options.CompressionOptions = new ZstandardCompressionOptions { Quality = 6 };
});

Imports Microsoft.Extensions.DependencyInjection

builder.Services.AddResponseCompression()
builder.Services.AddRequestDecompression()
builder.Services.Configure(Of ZstandardCompressionProviderOptions)(Sub(options)
    options.CompressionOptions = New ZstandardCompressionOptions With {.Quality = 6}
End Sub)

既に zstd に対応しているクライアントに JSON やテキストペイロードを提供する API では、サードパーティライブラリに依存せずに、測定可能な帯域幅の向上が得られます。モバイルや gRPC 近傍のエコシステムにおいて普及しています。 また、特筆すべきこととして、これは Microsoft 社内におけるものではなく、コミュニティの貢献であり、健全なシグナルです。

BlazorのVirtualize<TItem>はついにすべての行が同じ高さであると仮定するのをやめました。 これは長い間イライラする要因でした: 可変コンテンツを含むリスト（コメント、チャットメッセージ、テキストを包むもの）が必要とされ、手動で回避策が必要でした。 今、コンポーネントはランタイムで項目を測定します。プレビュー3リリースでは次のようなBlazorバグが大量修正されています：Virtualize内のヌルリファレンス、overflow-xを伴うスクロールコンテナ検出、公開されたWASMアプリ内のWeb Workerテンプレート、IJSObjectReferenceリーク。 個々には小さいですが、フレームワークが"新しいことが毎リリース出てくる"段階から成熟しつつあることを示す一種のクリーンアップです。

Kestrel は、新しい接続でコントロールストリームと SETTINGS フレームを待たずに HTTP/3 リクエストを処理し始め、初リクエストの待ち時間を短縮します。 HTTP/3 の P99s を測定し、奇妙なコールドスタートの尾部を見ている場合、これが役立ちます。

.NET MAUI

プレビュー 3 における MAUI は、しばらくの間ベータ版のように感じるギャップを埋めることに焦点を当てています。 Mapコントロールは、ピンクラスターリング、カスタムピンアイコン、カスタムJSONスタイリング、円形、ポリゴン、およびポリライン上のクリックイベントを取得します。これは、実際のプロダクションマップUIが必要とし、以前はプラットフォームごとにカスタムハンドラーが必要だったすべての要素です。 組み込みの LongPressGestureRecognizer が利用可能になり、自分で作る必要がなくなりました。 暗黙の XAML 名前空間宣言がデフォルトでオンになり、すべてのファイルの一番上のボイラープレートを削減します。

プラットフォームの均等性が向上します：Permissions.PostNotificationsがiOSで実装されました（以前はAndroid限定でした）、AndroidはAndroid 17とAPIレベル37のプレビューサポートを獲得します。

正直な評価: これは安定した、合理的な反復であり、再発明ではありません。 2026年の MAUI は 2023年の MAUI よりもはるかに良い状態ですが、その初期の時代にそれを去った場合、プレビュー 3 だけでは戻ってきません。 既に MAUI を使用している場合、これらは正確にあなたが望んでいる QoL の変更です。

SDK、CLI、.NET watch

これは小さなことが合計されるセクションです。日常のワークフローを本当に変えると思われるいくつかのこと:

.NET sln は、CLI から直接ソリューションフィルター（.slnf）を作成および編集できるようになりました。 モノリポや大規模な Microsoft スタイルのソリューションにおいて、200 プロジェクトの SLN を開いてその中の 3 つに取り組むのは真に費用がかかっています。今では端末からスコープを指定できます:

dotnet new slnf --name MyApp.slnf
dotnet sln MyApp.slnf add src/Lib/Lib.csproj

dotnet new slnf --name MyApp.slnf
dotnet sln MyApp.slnf add src/Lib/Lib.csproj

ファイルベースのアプリ（.NET run app.cs ワークフロー）は最終的に #:include をサポートし、これにより C# スクリプトはヘルパーを別々のファイルに分割できます。 Roslyn でのディレクティブのエディター補完と組み合わせて、.NET ベースのファイルアプリを"おもちゃ"から"実際のオートメーションツールに適すもの"に促します - PowerShell や小規模な Python スクリプトが何年もリードしてきたニッチです。

.NET run -e FOO=BAR は、シェルの状態をエクスポートしたり、起動プロファイルを編集せずに、環境変数をコマンドラインで渡すことができます。 小さなことですが、異なるASPNETCORE_ENVIRONMENT値を持つ3つの端末を開いていたことがあるなら、その苦痛をご存じでしょう。

.NET watch は、Aspire アプリホストと統合し、クラッシュ後にファイル変更ごとに自動で再起動し、WinForms や WPF において Ctrl+C をより優雅に扱います（永遠のペーパーカット）。 .NET format はマルチターゲットプロジェクト向けに --framework を受け入れます。 MTP モードでの .NET test は --artifacts パスをサポートします。 .NET tool exec / dnx はもはや追加の承認を求めず、ワンオフツールの実行の摩擦点を解消します。

痛点

バランスの取れたレビューが粗削りな面を説明し、プレビュー 3 はそれを有しています。

ツールの物語は粗いです。 Visual Studio 2026 は .NET 10 が出荷されてから 6 ヶ月が経過してもまだプレビュー段階にあり、Microsoft ホスティングビルドエージェントは安定した VS 2026 サポートをまだ提供していません。 .NET 10 SDK パッチリリースの変更で MSBuild 18（VS 2026）が必要とされ、Microsoft が宣伝する semver の保証に違反しています。 Microsoft ホスティングのエージェント上で CI を実行している人は SDK 10.0.4 をピン止めするか、プレビュー ビルド イメージに切り替える必要がありました。 .NET 11 プレビューへの CI パイプライン移行を検討している場合、同じことを期待してください - チーム自身の認識において、プレビュー SDK は 10.0.2 および 10.0.3 で物を壊し、それから安定します。

ランタイム非同期はまだオプトインです。 プレビュー機能ゲートがなくなっても、runtime-async=onを切り替える必要があります。 これは、新しいフィールドコードでは問題ありません。 NuGet で出荷されるライブラリの場合、消費者がスイッチをオンにしていることを前提にできないため、機能のデフォルトがオンになるまでは実質上の利益は延期されます（.NET 11 ではありません）。

ハードウェア要件の増加。 最小 x86/x64 命令セット要件が上がりました。ほとんどのチームは気づかないでしょう。あるチームは - あらかじめ監査しなければデプロイ時間にそれを知ることになります。

STS、ではなく LTS。 .NET 11 は 24 ヶ月間サポートされます。 現在の LTS である .NET 10 は 36 ヶ月間サポートされます。 ゆっくりしたアップグレードのペースを持つショップにとって、.NET 10 は依然としてより保守的な選択であり、.NET 11 の採用は 2028 年にもう 1 つのアップグレードをコミットすることを意味します。STS の採用の理由は機能ですが、 理由に反対するものはカレンダーです。

プレビューとはプレビューを意味します。 これは安定性の否定ではありません - Microsoft のプレビュープロセスは良好です - しかし、プレビュー 3 はリリース候補ではありません。 最も早くて RC1 でプロダクション展開を待ちます。内部ツール、サイドプロジェクト、探求は今の段階で正しい範囲です。

評決

毎日 C# を書いているなら、.NET 11 プレビュー 3 は今週インストールして遊ぶ価値があります - 特に、何年も前の最も重要な言語の変化であるユニオンタイプを手にするために。 ライブラリをメンテナンスしているなら、JIT とランタイム非同期の作業は、編集なしで .NET 11 でコードが速くなることを意味し、これは最高のアップグレードです。 MAUI アプリを出荷しているなら、地図とジェスチャーの作業は本当に進展です。

製品 .NET ワークロードを実行しているなら、答えは退屈なものです: 計画を続け、ウォッチし、そして 11 月に GA をブックマークします。 興奮させるものは着陸していますが、ツーリングチェーン - VS、ビルドエージェント、SDK パッチのリズム - が実際には摩擦を引き起こしており、まだ解決されていません。

| --- |

ソース: .NET ブログの発表, .NET 11 の新機能 (Microsoft Learn), Runtime リリースノート, ASP.NET Core リリースノート, SDK リリースノート, C# 15 でのユニオンタイプの探求。