.NET 11 Preview 6の破壊的変更まとめ｜OpenAPI 3.2・MAUI・コンテナ検証手順

.NET 11 Preview 6で既存アプリやCI、コンテナイメージへの影響を短時間で確認するなら、最優先で見るべきなのは、OpenAPI 3.2への既定変更、自動CSRF保護、.NET MAUIのCompatibilityパッケージ削除、Azure Linux 4.0ベースイメージ、Preview間のAPI変更です。

単にビルドが成功するかを見るだけでは不十分です。OpenAPIの生成結果、ブラウザからのフォーム送信、MAUIのAndroid画面遷移、EF Coreが生成するSQL、コンテナ内のネイティブ依存関係まで確認する必要があります。

.NET 11 Preview 6は2026年7月14日に公開され、Runtime、SDK、ライブラリ、ASP.NET Core、.NET MAUI、C#、EF Core、F#、コンテナイメージが更新されました。SDKは11.0.100-preview.6.26359.118です。ただし、Preview版は原則として本番利用のサポート対象ではないため、既存環境へ直接上書きせず、隔離した開発環境やCIジョブで評価するのが安全です。(Microsoft for Developers)

.NET 11 Preview 6で優先的に確認すべき変更

.NET 11 Preview 6には多数の新機能がありますが、既存アプリへの影響という観点では、すべてを同じ深さで検証する必要はありません。まずは次の順序で確認すると効率的です。

優先度	対象	主な変更	発生し得る症状
高	ASP.NET Core	OpenAPI 3.2が既定	APIクライアント生成、APIゲートウェイへの取り込み、スキーマ検証の失敗
高	ASP.NET Core	自動CSRF保護	外部サイトや別オリジンからのフォームPOSTがHTTP 400になる
高	.NET MAUI	Compatibilityパッケージ削除	NuGet復元失敗、ビルドエラー、旧Renderer依存機能の停止
高	Containers	Azure Linux 4.0 Betaへ移行	ネイティブライブラリ、証明書、権限、AOTビルドの差異
中	EF Core	SQL変換とSQLite依存パッケージ変更	SQLの形、実行計画、RID別発行物の変化
中	SDK・CI	`dotnet test`の出力やMTP動作の変更	コンソール出力を解析するCIスクリプトの失敗
中	C#・Libraries	Union対応、`Process.Run`の引数変更	Preview追随コードのコンパイルエラー、JSON契約の変化
低～中	F#・Runtime	FSI出力、JIT、Runtime Asyncなどの改善	標準出力を解析する処理や性能特性の変化

ここでいう「影響」には、正式に破壊的変更として分類されたものだけでなく、既定値変更、ベースイメージ変更、出力形式変更のような回帰リスクも含みます。

Preview SDKは既存環境から隔離して導入する

Preview SDKを端末全体の既定SDKにすると、関係のないリポジトリまでPreview 6でビルドされる恐れがあります。専用ディレクトリ、使い捨ての仮想マシン、コンテナ、または専用CIランナーへ導入してください。

リポジトリにはglobal.jsonを置き、使用するSDKを固定します。

{
  "sdk": {
    "version": "11.0.100-preview.6.26359.118",
    "rollForward": "disable",
    "allowPrerelease": true
  }
}

SDKを導入した後は、最初に実際の選択状態を確認します。

dotnet --version
dotnet --info

プロジェクトは検証用ブランチでnet11.0へ変更します。安定版との比較を続ける場合は、可能なプロジェクトに限りマルチターゲット化する方法もあります。

<PropertyGroup>
  <TargetFrameworks>net10.0;net11.0</TargetFrameworks>
</PropertyGroup>

最初のビルドでは、依存パッケージが意図せず変わっていないかを確認するため、ロックモードを使うと問題を発見しやすくなります。

dotnet restore --locked-mode
dotnet build -c Release -warnaserror
dotnet test -c Release --no-build --logger "trx;LogFileName=preview6.trx"

--locked-modeで失敗した場合、すぐにロックファイルを作り直すのではなく、どのパッケージが変わったのかを確認してください。EF Coreや.NET MAUIなど、Preview 6に合わせた更新が必要な依存関係だけを明示的に変更します。

OpenAPI 3.2への既定変更はAPI契約テストが必須

ASP.NET Core 11 Preview 6では、組み込みのAddOpenApiで生成するOpenAPIドキュメントの既定バージョンがOpenAPI 3.2になりました。生成処理のコードを変更していなくても、出力される仕様バージョンが変わります。Microsoftはこの変更を「動作の変更」に分類しています。(GitHub)

影響を受けやすいのは、次のような構成です。

OpenAPIファイルからクライアントSDKを自動生成している
APIゲートウェイや管理サービスへOpenAPIファイルをインポートしている
CIでOpenAPIスキーマをLintしている
OpenAPIファイルをGitで管理し、差分を承認している
ドキュメント生成ツールが特定の仕様バージョンを前提としている

生成結果を差分比較する

現在利用している安定版からOpenAPIファイルを生成し、Preview 6の出力と比較します。エンドポイントのパスはアプリに合わせて変更してください。

curl -fsS https://localhost:5001/openapi/v1.json \
  -o openapi-preview6.json

git diff --no-index \
  openapi-baseline.json \
  openapi-preview6.json

単に先頭のopenapiが3.2.0へ変わったかを見るだけでなく、次の項目も確認します。

components.schemasの構造
nullable表現
anyOf、oneOf、allOf
enumと既定値
リクエストボディの必須判定
レスポンス型
セキュリティスキーム
クライアント生成後のメソッド名と型

比較後は、実際に利用しているクライアント生成、APIゲートウェイへのインポート、Lint、ドキュメント生成まで通してください。JSONファイルが正しく見えても、下流ツールがOpenAPI 3.2を受理できるとは限りません。

OpenAPI 3.1へ一時的に固定する方法

下流ツールがOpenAPI 3.2に対応していない場合は、バージョンを明示してOpenAPI 3.1へ固定できます。

builder.Services.AddOpenApi(options =>
{
    options.OpenApiVersion =
        Microsoft.OpenApi.OpenApiSpecVersion.OpenApi3_1;
});

これは互換性を維持するための一時的な対応です。CIを通すためだけに固定するのではなく、「どの外部システムが3.2を処理できないのか」「いつ固定を解除するのか」を課題として記録しておきます。(Microsoft Learn)

C# Unionを使う場合はJSONとOpenAPIを同時に確認する

Preview 6では、C# Unionのサポート型がフレームワークに含まれるようになり、System.Text.JsonとASP.NET CoreでもUnionを扱えるようになりました。OpenAPIでは各ケースがanyOfとして表現されます。

一方、MicrosoftのPreview 6リリースノートでは、SwashbuckleやNSwagなどのサードパーティー生成ツールは、現時点でUnionを認識せず、それぞれの既定のスキーマを生成すると説明されています。Unionは引き続きプレビュー機能であり、<LangVersion>preview</LangVersion>が必要です。(GitHub)

Unionを試している場合は、次の3つをセットでスナップショットテストしてください。

実際のJSONレスポンス
組み込みAddOpenApiの出力
SwashbuckleやNSwagなど、実運用で使う生成ツールの出力

自動CSRF保護で別オリジンのフォーム送信が変わる

ASP.NET Core 11 Preview 6では、WebApplication.CreateBuilderで構築したアプリに、自動的なクロスオリジンCSRF保護が追加されます。

既定の実装は、ブラウザが送信するSec-Fetch-SiteとOriginを使ってリクエスト元を判定します。同一オリジン、利用者が開始したナビゲーション、一般的な非ブラウザクライアントは許可されます。一方、信頼されていない別オリジンからフォームデータを処理しようとするリクエストは拒否されます。Minimal API、MVC、Razor Pages、Blazorが対象です。(GitHub)

最低限実施したいCSRFテスト

テストケース	既定動作で期待する結果
同一オリジンからのフォームPOST	通常どおり処理される
未許可オリジンからのフォームPOST	HTTP 400
`WithOrigins`で明示した信頼済みオリジン	通常どおり処理される
`Origin`を送らないサーバー間通信	自動CSRF保護では許可される
Bearer Tokenを使うJSON API	フォームを読み取らなければ通常は影響しない
Cookie認証を使うブラウザ向け更新API	安易に保護を無効化しない

未許可オリジンを再現する例は次のとおりです。フォームを読み取るエンドポイントに対して実行します。

curl -i -X POST "https://localhost:5001/profile" \
  -H "Origin: https://untrusted.example" \
  -H "Sec-Fetch-Site: cross-site" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  --data "displayName=test"

通常のcurlはブラウザ由来のヘッダーを送信しないため、単にcurlを実行するだけではクロスサイト判定を再現できません。上記のようにヘッダーを明示する必要があります。

CORSのAllowAnyOriginでは信頼済みにならない

AllowAnyOriginは、自動CSRF保護における信頼済みオリジンとしては扱われません。読み取りを許可するCORS設定と、Cookieを伴う状態変更を信頼する判断は別だからです。

別オリジンから正規のフォーム送信を受け付ける場合は、WithOriginsで送信元を個別に指定します。[DisableCors]もCSRF保護の無効化にはなりません。(Microsoft Learn)

Webhookだけを個別に除外する

ブラウザから呼び出されず、Cookie認証も使用しないWebhookなどは、エンドポイント単位で除外できます。

app.MapPost("/webhooks/provider", (
    WebhookPayload payload) =>
{
    return Results.Accepted();
})
.DisableAntiforgery();

MVCでは[IgnoreAntiforgeryToken]を使用できます。

ただし、Cookie認証を使うブラウザ向けエンドポイントで無効化してはいけません。アプリ全体のDisableCsrfProtectionは緊急回避用であり、通常はエンドポイント単位の設定を優先します。(Microsoft Learn)

Preview検証中は、既存のトークンベースAntiforgeryを同時に削除しない方が安全です。まず自動保護を追加した状態で回帰テストし、セキュリティ方式の変更は別の作業として評価します。

.NET MAUIはCompatibilityパッケージの参照を最初に検索する

.NET 11 Preview 6では、Xamarin.Formsからの移行支援用だったMicrosoft.Maui.Controls.Compatibilityパッケージがビルド・配布されなくなりました。

影響を受けるのは、このパッケージを明示的に参照しているアプリ、または旧Xamarin.Forms互換Rendererへ依存しているアプリです。Microsoft.Maui.Controlsだけを参照しているアプリは、今回のパッケージ削除そのものでは影響を受けません。(GitHub)

参照状況を確認する

Preview 6へ切り替える前のブランチで、プロジェクトファイルと依存パッケージを確認します。

git grep -n "Microsoft.Maui.Controls.Compatibility"

dotnet list src/MyApp/MyApp.csproj \
  package --include-transitive

直接参照がなくても、古いUIコンポーネントや社内ライブラリが依存している可能性があります。次の名前もソースコード内で検索してください。

git grep -n -E \
  "ShellRenderer|ShellFlyoutRenderer|ShellItemRenderer|ShellSectionRenderer"

Compatibilityパッケージが見つかった場合、削除されたパッケージを無理に追加し直すのではなく、Handlerベースの実装へ移行します。

AndroidのShellは画面操作まで確認する

Preview 6では、Android版Shellが従来のRendererから標準的なMAUI Handlerベースへ再実装されています。iOSとMac Catalystは、このPreview時点では従来のShell Rendererを継続しています。(GitHub)

Androidでは、ビルド成功だけでなく次の操作を実機またはエミュレーターで確認します。

Flyoutの開閉
タブの切り替え
戻るボタン
画面遷移とナビゲーションスタック
Deep Link
端末回転
アプリの中断と復帰
独自Handlerや旧Rendererを使う画面
UI自動テスト
スクリーンリーダーやフォーカス移動

ワークロードを含めて復元したうえで、対象プラットフォームを明示してビルドします。

dotnet workload restore

dotnet build src/MyApp/MyApp.csproj \
  -c Release \
  -f net11.0-android

Azure Linux 4.0コンテナイメージはOS更新として検証する

.NET 11 Preview 6のAzure Linux系コンテナイメージは、Azure Linux 3.0からAzure Linux 4.0 Betaへ更新されました。runtime-deps、runtime、aspnet、sdkに加え、Native AOT、distroless、ASP.NET Core compositeの各バリアントでazurelinux4.0タグが提供されます。(GitHub)

タグの例は次のとおりです。

FROM mcr.microsoft.com/dotnet/sdk:11.0-preview-azurelinux4.0 AS build

# restore、build、publish

FROM mcr.microsoft.com/dotnet/aspnet:11.0-preview-azurelinux4.0 AS final

これは単なる.NET Runtimeの更新ではなく、コンテナのベースOS更新として扱う必要があります。

コンテナで確認する項目

x64とArm64でイメージをビルドできるか
アプリが起動し、ヘルスチェックへ応答するか
HTTPSで外部サービスへ接続できるか
社内CA証明書を正しく読み込めるか
タイムゾーンとカルチャ依存処理が正しいか
PDF、画像、暗号化などのネイティブライブラリを読み込めるか
非rootユーザーで必要なディレクトリへ書き込めるか
SIGTERMを受けて正常終了できるか
KubernetesのReadiness、Liveness、Startup Probeが通るか
SBOMと脆弱性スキャンが組織の基準を満たすか

シェルを含むイメージであれば、OS情報を確認できます。

docker run --rm \
  --entrypoint /bin/sh \
  app:net11-preview6 \
  -c "cat /etc/os-release && dotnet --info"

distrolessイメージにはシェルがないため、この方法は使えません。その場合は、デバッグ用バリアントまたはビルド工程でOS情報と依存ファイルを検証します。

検証が完了したコンテナは、浮動タグだけでなくダイジェストで固定すると、同じPreviewタグの更新による再現性低下を避けられます。

Native AOTはコンパイラの前提も変わる

Preview 6のNative AOT SDKイメージでは、Clang／LLVMからGCCへ変更され、AOTに必要な最小限のコンパイラ、リンカー、開発パッケージだけが含まれる構成になりました。(GitHub)

次のようなビルド処理は重点確認が必要です。

clangコマンドを直接呼び出している
Clang固有のオプションを指定している
SDKイメージ内の追加パッケージを暗黙に利用している
ネイティブ静的ライブラリをリンクしている
AOTビルド結果を複数アーキテクチャへ発行している

イメージサイズが小さくなっていても、必要なビルドツールまで削除されていないかを先に確認してください。

EF Coreは「同じ結果」だけでなく生成SQLを比較する

EF Core Preview 6では、LINQ変換、複合型内プロパティへのキー・インデックス設定、マイグレーションなどが改善されています。たとえば、これまでクライアント側評価になっていた一部の式がSQLへ変換されるようになるため、結果が同じでもSQLや実行計画が変わる可能性があります。(GitHub)

重要なクエリでは、次を比較します。

ToQueryString()で取得したSQL
SQLパラメーター
NULLの扱い
並び順
発行クエリ数
実行計画
インデックスの使用状況
処理時間
トランザクション境界

マイグレーションについても、意図しないモデル差分がないかを確認します。

dotnet ef migrations has-pending-model-changes

検証用データベースでは、既存のマイグレーションを最初から適用するテストと、現在の本番相当スキーマから更新するテストの両方を実施してください。

Microsoft.Data.Sqliteのネイティブ依存関係が変わる

Preview 6では、Microsoft.Data.Sqliteの依存先がe_sqlite3からSQLite3MC.PCLRaw.bundleへ変更されました。(GitHub)

SQLiteを利用するアプリでは、次を確認します。

NuGetロックファイルの変更
Windows、Linux、macOSの各RIDでの発行物
コンテナ内での起動
MAUIアプリ内でのデータベース初期化
単一ファイル発行
Native AOT
ネイティブライブラリの重複
既存SQLiteファイルの読み書き

特にMAUI、デスクトップアプリ、コンテナでSQLiteを利用している場合は、復元成功だけでなく実際のデータベース接続まで試します。

C# Preview機能はコンパイラ、JSON、API契約をまとめて見る

Preview 6では、Extension Indexerが追加され、Union用のUnionAttributeとIUnionがフレームワークに含まれるようになりました。どちらもプレビュー機能です。(GitHub)

通常の既存C#コードへの直接的な影響は限定的ですが、Preview 5までのUnionを試していたプロジェクトでは注意が必要です。フレームワークに同等のサポート型が入ったため、手動で定義していた型が残っていないかを確認します。

git grep -n -E "UnionAttribute|IUnion|public union"

UnionをAPIのリクエストやレスポンスへ使う場合は、次の互換性を別々に確認してください。

C#コンパイル
System.Text.Jsonのシリアライズ
デシリアライズ
OpenAPIスキーマ
生成クライアント
SignalR
Blazorの状態保存

Preview 5以前から追随している場合のソース互換性

.NET 10などの安定版から初めてPreview 6を試す場合と、Preview 1～5を継続利用している場合では、確認対象が異なります。

Process.RunとProcess.RunAsync

.NET Librariesでは、先行する.NET 11 Previewで追加されたProcess.RunとProcess.RunAsyncのfileNameオーバーロードに、silent引数が追加されました。既存のオプション引数より前に入るため、タイムアウトやCancellationTokenを位置引数で渡していたPreviewコードは修正が必要です。

名前付き引数または既定値を使う呼び出しは影響を受けません。これは.NET 10の既存APIではなく、以前の.NET 11 Previewを利用していたコードへの影響です。(GitHub)

修正時は位置引数を増やすだけでなく、名前付き引数へ変更すると今後のPreview更新に追随しやすくなります。

await Process.RunAsync(
    fileName: "tool",
    silent: false,
    timeout: timeout,
    cancellationToken: cancellationToken);

ASP.NET CoreのPreview API名変更

Preview 4やPreview 5でBlazorのブラウザ設定APIを使っている場合、次の変更があります。

WithBrowserConfigurationからWithBrowserOptions
BrowserConfigurationからBrowserOptions
ServerBrowserOptionsからInteractiveServerBrowserOptions
CircuitInactivityTimeoutMsからCircuitInactivityTimeout
DisableDomPreservationからPreserveDom

特にDisableDomPreservationからPreserveDomへの変更は、名前だけでなく真偽値の意味が反転しています。機械的にプロパティ名だけを置換すると、意図と逆の動作になる可能性があります。(GitHub)

また、Minimal APIの検証Resolverを直接実装している場合は、IValidatableInfoの分割などに対応する必要があります。標準の[ValidatableType]とAddValidation()だけを利用しているアプリは、このAPI変更の影響を受けません。(GitHub)

SDKとCIはコンソール出力を正解データにしない

.NET 11 Preview 6では、Microsoft.Testing.Platformを使うdotnet testに複数の変更が入っています。

主な変更は、アセンブリ単位のテスト件数表示、標準出力・標準エラーのライブ転送、Terminal Logger引数のMSBuildへの転送、新しいオプションの追加などです。(GitHub)

そのため、次のようなCIは壊れやすくなります。

dotnet testのコンソール文字列を正規表現で解析している
「Passed」「Failed」の表示位置を前提としている
標準出力と標準エラーの混在を前提としている
Terminal Loggerの引数をテストアプリへ渡している
VSTestとMicrosoft.Testing.Platformを暗黙に切り替えている

CIではコンソール文字列ではなく、TRXやJUnitなどの構造化されたテスト結果を利用してください。

Preview 6では環境変数でテストランナーを切り替えられるため、VSTestとMicrosoft.Testing.Platformの比較もできます。

DOTNET_TEST_RUNNER=VSTest dotnet test

DOTNET_TEST_RUNNER=Microsoft.Testing.Platform dotnet test

同じテスト数、終了コード、成果物、カバレッジ結果になるかを確認します。

F#とRuntimeは利用箇所に応じて重点を変える

F#では、dotnet fsi --quiet実行時のNuGet復元メッセージが標準出力へ混ざらなくなりました。機械可読な結果を標準出力へ出しているスクリプトには改善ですが、標準出力の内容を完全一致で検証しているCIでは差分になります。

また、署名ファイルに必要な属性が不足している場合の診断が追加され、プレビュー言語機能の設定によってはエラーになります。.fsiファイルを厳格に運用しているプロジェクトは、警告をエラーとして扱うビルドも確認してください。(GitHub)

Runtime側のPreview 6は、Runtime Async、JIT、クラッシュレポート、Native AOT、SIMDなどの性能・診断改善が中心です。(GitHub)

性能が重要なサービスでは、平均値だけでなく次の指標を安定版と比較します。

起動時間
P50、P95、P99レイテンシ
スループット
GC回数
割り当て量
CPU使用率
ワーキングセット
Native AOTのイメージサイズ
例外時のログとクラッシュ情報

JITや非同期処理の最適化では、タイミングが変わることで潜在的な競合状態が表面化することもあります。性能テストだけでなく、並列処理、キャンセル、タイムアウト、シャットダウンの回帰テストも実施します。

60分で実施する回帰テストの進め方

すべての新機能を試すのではなく、既存システムへの影響を短時間で把握するなら、次の順序が現実的です。

時間の目安	作業	合格条件
0～10分	SDK固定、復元、Releaseビルド	意図しないSDK選択やパッケージ更新がない
10～20分	OpenAPI生成と下流ツール実行	3.2を処理できる、または3.1固定の判断ができる
20～30分	CSRFテスト	同一オリジン、未許可オリジン、Webhookが想定どおり
30～40分	MAUIまたはEF Core	削除パッケージ、Android Shell、SQL差分を把握できる
40～50分	Azure Linux 4.0コンテナ	ビルド、起動、TLS、ネイティブ依存、Probeが正常
50～60分	CIと成果物の比較	テスト件数、終了コード、ログ、発行物が承認可能

MAUIを使っていない場合は、その時間をEF CoreのSQL比較、C# Unionの契約テスト、Native AOT検証へ割り当てます。

更新を進めてよいか判断する基準

次の条件を満たせた場合は、Preview 6を開発・検証環境で継続評価できます。

SDKのバージョンをリポジトリ単位で固定できた
OpenAPIを利用するすべての下流ツールで結果を確認した
CSRFの許可・拒否が設計どおりになった
MAUI Compatibilityパッケージへの依存がない、または移行方針が決まった
Android Shellの主要操作を実機またはエミュレーターで確認した
EF Coreの主要クエリとマイグレーション差分を確認した
Azure Linux 4.0コンテナで本番相当の起動試験を通した
CIがコンソール文字列ではなく構造化結果を利用している
JSON、OpenAPI、SQL、コンテナ成果物の差分を承認できた

反対に、外部のAPI利用者がOpenAPI 3.2を処理できない、別オリジンのフォーム連携が把握できていない、MAUIの旧Renderer依存が残っている、Azure Linux 4.0でネイティブ依存関係が解決できない、といった状態では更新を保留すべきです。

.NET 11 Preview 6は、新機能を一通り試すよりも、OpenAPI、CSRF、MAUI依存関係、EF CoreのSQL、Azure Linux 4.0コンテナの5点を先に回帰テストする方が、既存システムへの影響を早く把握できます。本番環境はサポート対象の安定版に維持し、Preview 6は隔離環境でSDKと成果物を固定しながら評価してください。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

.NET 11 Preview 6の破壊的変更まとめ｜OpenAPI 3.2・MAUI・コンテナ検証手順

.NET 11 Preview 6で優先的に確認すべき変更

Preview SDKは既存環境から隔離して導入する

OpenAPI 3.2への既定変更はAPI契約テストが必須

生成結果を差分比較する

OpenAPI 3.1へ一時的に固定する方法

C# Unionを使う場合はJSONとOpenAPIを同時に確認する

自動CSRF保護で別オリジンのフォーム送信が変わる

最低限実施したいCSRFテスト

CORSのAllowAnyOriginでは信頼済みにならない

Webhookだけを個別に除外する

.NET MAUIはCompatibilityパッケージの参照を最初に検索する

参照状況を確認する

AndroidのShellは画面操作まで確認する

Azure Linux 4.0コンテナイメージはOS更新として検証する

コンテナで確認する項目

Native AOTはコンパイラの前提も変わる

EF Coreは「同じ結果」だけでなく生成SQLを比較する

Microsoft.Data.Sqliteのネイティブ依存関係が変わる

C# Preview機能はコンパイラ、JSON、API契約をまとめて見る

Preview 5以前から追随している場合のソース互換性

Process.RunとProcess.RunAsync

ASP.NET CoreのPreview API名変更

SDKとCIはコンソール出力を正解データにしない

F#とRuntimeは利用箇所に応じて重点を変える

60分で実施する回帰テストの進め方

更新を進めてよいか判断する基準

この記事を書いた人

コメント

コメントするコメントをキャンセル

.NET 11 Preview 6の破壊的変更まとめ｜OpenAPI 3.2・MAUI・コンテナ検証手順

.NET 11 Preview 6で優先的に確認すべき変更

Preview SDKは既存環境から隔離して導入する

OpenAPI 3.2への既定変更はAPI契約テストが必須

生成結果を差分比較する

OpenAPI 3.1へ一時的に固定する方法

C# Unionを使う場合はJSONとOpenAPIを同時に確認する

自動CSRF保護で別オリジンのフォーム送信が変わる

最低限実施したいCSRFテスト

CORSのAllowAnyOriginでは信頼済みにならない

Webhookだけを個別に除外する

.NET MAUIはCompatibilityパッケージの参照を最初に検索する

参照状況を確認する

AndroidのShellは画面操作まで確認する

Azure Linux 4.0コンテナイメージはOS更新として検証する

コンテナで確認する項目

Native AOTはコンパイラの前提も変わる

EF Coreは「同じ結果」だけでなく生成SQLを比較する

Microsoft.Data.Sqliteのネイティブ依存関係が変わる

C# Preview機能はコンパイラ、JSON、API契約をまとめて見る

Preview 5以前から追随している場合のソース互換性

Process.RunとProcess.RunAsync

ASP.NET CoreのPreview API名変更

SDKとCIはコンソール出力を正解データにしない

F#とRuntimeは利用箇所に応じて重点を変える

60分で実施する回帰テストの進め方

更新を進めてよいか判断する基準

この記事を書いた人

関連記事

コメント

コメントする コメントをキャンセル

コメントするコメントをキャンセル