Microsoft developer platformでPackage Uploaderを使っている場合、今回の「Update to .NET 10」で最初に確認すべきことは、利用しているPackage Uploaderが最新版か、ビルド環境に.NET 10 SDKが入っているか、CI/CDや自作拡張でSystem.CommandLine.Hostingに依存していないかの3点です。
2026年5月5日にマージされたPull Request #117では、Package Uploaderが.NET 10へ更新され、古いSystem.CommandLine.Hostingの利用が削除されました。既存の実行ファイルをダウンロードして使うだけなら影響は比較的小さい一方、GitHub ActionsやAzure Pipelinesでソースからビルドしているチーム、DLLを組み込んでいるチーム、CLIまわりをフォーク・改修しているチームは、早めに移行確認を進めるべき更新です。(GitHub)
Microsoft developer platformの更新で何が変わったか
今回の更新は、Microsoft developer platform関連のPackage Uploaderに対する.NET 10対応です。Package Uploaderは、Partner Centerへゲームパッケージをアップロードする処理を自動化するためのツールで、コマンドラインツールとDLLをビルドパイプラインや開発ワークフローに組み込めます。README上でも、現在のPackage Uploaderは「.NET 10.0ベースのクロスプラットフォームアプリおよびライブラリ」と説明されています。(GitHub)
Pull Request #117の主な変更は次のとおりです。
| 変更点 | 内容 | 実務上の確認ポイント |
|---|---|---|
| .NET 10への更新 | プロジェクト、CI、依存パッケージ、READMEなどが.NET 10前提に更新 | ローカルPC、ビルドサーバー、GitHub Actions、Azure Pipelinesに.NET 10 SDKがあるか確認 |
System.CommandLine.Hostingの削除 | 非推奨パッケージへの依存をやめ、System.CommandLine v2を使う構成へ変更 | 自作CLIやフォークで同パッケージを参照していないか確認 |
| テスト基盤の更新 | MSTest.SdkやMicrosoft.Testing.Platform v2など、テスト関連の構成が刷新 | テストプロジェクトのターゲットフレームワーク、テスト実行コマンド、CIの失敗有無を確認 |
| パッケージロックファイルの有効化 | 依存パッケージの復元を安定させるため、lock file関連の変更が追加 | dotnet restore --locked-modeで復元できるか確認 |
| 公開スクリプトと出力パスの更新 | Windows/Linux向けpublishスクリプトや出力先が更新 | CIが古い出力パスからPackageUploader.exeを取得していないか確認 |
| ドキュメント更新 | READMEや実装ドキュメント内の.NETバージョン、ビルド手順が更新 | 社内手順書、Wiki、リリース手順を.NET 10前提に直す |
PRの概要では、アプリ本体、クライアントAPI、ファイルロガー、UI、テスト、publishスクリプト、CI、ドキュメントまで広く変更されたことが示されています。単なるREADME修正ではなく、開発・ビルド・テスト・配布の流れ全体に関わる更新と捉えるのが安全です。(GitHub)
なぜ.NET 10へ更新されたのか
大きな理由は、.NET 8のサポート終了が近づいているためです。Microsoftのライフサイクル情報では、.NET 8 LTSの終了日は2026年11月10日、.NET 10の終了日は2028年11月14日とされています。(Microsoft Learn)
つまり、2026年5月時点で.NET 8ベースのまま運用しているツールは、残り半年ほどでサポート期限に到達します。Package Uploaderのようにビルドパイプラインや公開作業に関わるツールは、サポート終了直前に慌てて更新すると、リリース作業そのものに影響が出やすくなります。
特に注意したいのは、次のようなケースです。
- 月次・週次でPartner Centerへのパッケージアップロードを自動化している
- リリース直前にPackage UploaderをCI/CDから実行している
PackageUploader.ClientApiなどのDLLを自社ツールに組み込んでいる- GitHubリポジトリをフォークして独自の操作やログ処理を追加している
- 実行ファイルではなく、ソースからビルドして社内配布している
実行ファイルを単体で使っている場合、READMEでは「.NETランタイムを別途インストールする必要はない」と説明されています。ただし、ソースからビルドする場合は.NET 10 SDK、またはそれ以降のSDKが必要です。(GitHub)
影響を受けるユーザーと対応優先度
今回のMicrosoft developer platform更新は、すべての利用者に同じ影響があるわけではありません。対応の優先度は、Package Uploaderをどう使っているかで変わります。
| 利用パターン | 影響度 | 対応の優先度 | 確認すべきこと |
|---|---|---|---|
| GitHub Releasesから最新実行ファイルをダウンロードして使うだけ | 低 | 中 | 最新版を取得し、GetProductやGetPackagesで認証と接続を確認 |
| Wingetでインストールしている | 中 | 中 | Winget版が最新とは限らないため、GitHub Releases版とのバージョン差を確認 |
| GitHub ActionsやAzure Pipelinesでソースからビルド | 高 | 高 | .NET 10 SDK、restore、build、test、publishの全工程を確認 |
| DLLを自社ツールに組み込み | 高 | 高 | 自社アプリのTargetFramework、依存パッケージ、認証処理、例外処理を確認 |
| Package UploaderをフォークしてCLIを改修 | 高 | 最優先 | System.CommandLine.Hosting依存、InvocationContext依存、古いAPI利用を洗い出す |
| テストプロジェクトを独自に追加 | 中〜高 | 高 | MSTest.Sdk、Microsoft.Testing.Platform v2、lock fileの復元を確認 |
特に、フォーク版を使っているチームは「本家が.NET 10に上がった」だけでなく、コマンドライン起動まわりの設計が変わった点に注意が必要です。PRでは、System.CommandLine.Hostingを削除し、System.CommandLine v2と独自のhost-builder構成へ置き換えたことが説明されています。(GitHub)
System.CommandLine.Hosting削除で確認すべきポイント
今回の更新で見落としやすいのが、System.CommandLine.Hostingの削除です。
NuGet上のSystem.CommandLine.Hostingは、レガシーで保守されていない非推奨パッケージと表示されています。また、System.CommandLineの開発側でも、System.CommandLine.Hostingを含む実験的プロジェクトを非推奨化し、今後のリリースから除外する方針が示されています。([nuget.org][5])
自社コードやフォーク版で、次のような参照が残っている場合は要注意です。
rg "System.CommandLine.Hosting|CommandLineBuilder|InvocationContext|ICommandHandler"Windows環境でripgrepがない場合は、PowerShellでも確認できます。
Select-String -Path .\**\*.cs,.\**\*.csproj -Pattern "System.CommandLine.Hosting","CommandLineBuilder","InvocationContext","ICommandHandler"該当箇所が見つかった場合は、単純にパッケージ参照を消すだけでは不十分です。System.CommandLine v2では、コマンドの定義、オプションの追加、解析結果の取得、アクションの設定方法が整理されています。Microsoft Learnの移行ガイドでも、API名の変更、変更可能なコレクション、名前とエイリアスの扱い、解析と呼び出しの分離など、破壊的変更が説明されています。([Microsoft Learn][6])
移行時に起きやすい失敗
System.CommandLine.Hostingから移行する際は、次のような失敗が起きやすくなります。
| 失敗しやすいポイント | 具体例 | 対処 |
|---|---|---|
| オプションの説明文がエイリアス扱いになる | 古いOption<T>コンストラクターの書き方をそのまま使う | Descriptionプロパティを明示的に設定する |
InvocationContext前提の処理が壊れる | context.ParseResultやcontext.GetCancellationToken()に依存 | ParseResultやCancellationTokenを直接受け取る設計へ変更 |
| DIとCLI引数の接続が崩れる | ホスト生成時にコマンドラインの解析結果を渡していた | 解析結果をもとにhost/config/logging/serviceを組み立てる |
| ヘルプ表示や終了コードが変わる | --helpや不正引数時の挙動が以前と異なる | CIで正常系だけでなく異常系もテストする |
| trim/AOTで警告や実行時エラーが出る | 反射や古いライブラリ依存が残る | trim analyzerを有効にし、publish結果で実行テストする |
System.CommandLine自体は、trim-friendlyでAOT対応のCLIアプリに向いていると説明されています。だからこそ、古いHosting依存を残したままでは、.NET 10時代の軽量配布やAOT配布のメリットを活かしにくくなります。(Microsoft Learn)
.NET 10対応で確認すべき移行チェックリスト
Package Uploaderを業務で使っている場合は、以下の順で確認すると抜け漏れを減らせます。
利用中のPackage Uploaderを棚卸しする
まず、どこでPackage Uploaderを使っているかを洗い出します。
確認対象は、開発者のPCだけではありません。CI/CD、リリース用VM、社内ツール、手順書、リリースチェックリスト、Wikiに古い実行ファイルや古いパスが残っていることがあります。
where PackageUploader.exeリポジトリ内では、次のように参照を検索します。
rg "PackageUploader|XboxGamePackageManager|publish.win-x64|System.CommandLine.Hosting|net8.0|net10.0"特にnet8.0とSystem.CommandLine.Hostingが見つかった場合は、移行対象として扱います。
.NET 10 SDKを準備する
ソースからビルドする場合は、.NET 10 SDKが必要です。READMEのビルド手順でも、.NET 10 SDKまたは最新バージョンのダウンロードが案内されています。(GitHub)
ローカル環境では、次のコマンドでSDKを確認します。
dotnet --list-sdksCIでは、GitHub Actionsのactions/setup-dotnetを.NET 10向けに設定します。PR内でも、CIが.NET 10 SDKを使うよう更新されています。(GitHub)
- uses: actions/setup-dotnet@v5
with:
dotnet-version: 10.0.xAzure Pipelinesの場合も、UseDotNet@2などで10.0.xを指定します。
restore、build、testを順番に確認する
.NET 10移行では、いきなりpublishまで進めるのではなく、復元、ビルド、テストを段階的に確認します。
dotnet restore
dotnet build --configuration Release --no-restore
dotnet test --configuration Release --no-buildパッケージロックファイルを使っている場合は、CIで次のように固定復元できるか確認します。
dotnet restore --locked-mode--locked-modeで失敗する場合は、依存パッケージが変更されているのにpackages.lock.jsonが更新されていない可能性があります。開発者のPCでは通るのにCIだけ落ちる場合、SDKバージョン、NuGetソース、lock fileの差を優先して確認してください。
publish出力先を確認する
PRでは、Windows/Linux向けpublishスクリプトや出力パスも更新されています。READMEでは、Windows向けに./publish.win-x64.ps1を実行した後、src\PackageUploader.Application\bin\release\win-x64\publishにPackageUploader.exeが出力されると説明されています。(GitHub)
古いCIで、たとえば次のような固定パスを参照している場合は注意が必要です。
bin\Release\net8.0\win-x64\publish
bin\Release\net10.0\win-x64\publish今回の更新後は、publishスクリプト側の出力パスに合わせて成果物の取得パスを見直します。ビルドは成功しているのに成果物アップロードで失敗する場合、最初に見るべきはこの出力パスです。
Package Uploaderの操作別にテストすべきこと
Package Uploaderは、Partner Center上の製品やブランチに対して、取得、アップロード、削除、インポート、公開などの操作を行います。READMEでは、GetProduct、GetPackages、UploadUwpPackage、UploadXvcPackage、RemovePackages、ImportPackages、PublishPackagesなどの操作が案内されています。(GitHub)
.NET 10移行後は、少なくとも次の順でテストすると安全です。
| テスト段階 | 実行する操作 | 目的 |
|---|---|---|
| 接続確認 | GetProduct | 認証、tenant、productId/bigIdの設定確認 |
| データ取得確認 | GetPackages | ブランチ名、flight名、market group名の確認 |
| dry runに近い確認 | ヘルプ表示、設定ファイル検証 | CLIオプション、エラーメッセージ、終了コードの確認 |
| 小規模アップロード | テスト用パッケージのアップロード | XFUSアップロード、タイムアウト、ログ出力の確認 |
| 公開処理 | sandboxやflightへの公開 | Partner Center側の状態遷移、待機処理、失敗時の復旧確認 |
本番パッケージでいきなりUploadXvcPackageやPublishPackagesを実行するのは避けましょう。まずはテスト用ブランチやsandboxで、認証、アップロード、公開待機、ログ出力の一連の流れを確認するのが現実的です。
認証方式の確認も忘れない
Package Uploaderでは、Browser、AppSecret、AppCert、Default、AzureCli、ManagedIdentity、AzurePipelines、ClientSecret、ClientCertificateなど、複数の認証方式がREADMEで説明されています。(GitHub)
.NET 10への更新そのものが認証設定を直接変えるとは限りません。ただし、依存パッケージやAzure Identity関連のコードも更新対象に含まれているため、認証は必ず再確認すべきです。PRの変更一覧にも、Managed IdentityやClient Certificate関連のTokenProvider更新が含まれています。(GitHub)
認証方式ごとの確認ポイント
| 認証方式 | 主な利用シーン | 確認ポイント |
|---|---|---|
| Browser | 開発者PC、GUI利用、手動実行 | 既定ブラウザーで認証できるか、複数tenant時に-tを指定しているか |
| AppSecret / ClientSecret | ヘッドレスCI、古い自動化環境 | secret期限、値の取り違え、Partner Center側の権限 |
| AppCert / ClientCertificate | 証明書ベースの自動化 | 証明書ストア、thumbprint、期限、実行ユーザー権限 |
| AzureCli | 開発者PCや一部CI | az login済みのアカウントが対象tenantに権限を持つか |
| ManagedIdentity | Azure上の実行環境 | マネージドIDにPartner Center関連の権限があるか |
| AzurePipelines | Azure Pipelines | サービス接続、フェデレーション、tenant設定 |
認証エラーは、.NET更新やCLI変更と混同されがちです。移行テストでは、最初にGetProductのような読み取り操作で認証だけを切り分けると、原因特定が早くなります。
trim、AOT、RID固有配布を使う場合の注意点
.NET 10では、CLIツールの配布方法として、RID固有、self-contained、trimmed、Native AOTなどの選択肢がより重要になります。Microsoft Learnでは、.NET SDK 10以降で、特定OS/アーキテクチャ向けの.NETツールを作成でき、self-containedやNative AOTにも対応できると説明されています。(Microsoft Learn)
ただし、trimやAOTは「オンにすれば必ず小さく速くなる」という単純なものではありません。反射、動的ロード、設定バインディング、シリアライズ、古いライブラリ依存があると、ビルド時警告や実行時エラーにつながります。
.NETのtrimmingでは、PublishTrimmedを有効にするとtrim解析も有効になり、互換性のない機能に関する警告を確認できます。警告を無視してpublishだけ通すのではなく、実行テストまで含めて確認することが重要です。(Microsoft Learn)
確認例は次のとおりです。
<PropertyGroup>
<TargetFramework>net10.0</TargetFramework>
<PublishTrimmed>true</PublishTrimmed>
<EnableTrimAnalyzer>true</EnableTrimAnalyzer>
</PropertyGroup>AOT配布を検討する場合は、まず通常のself-contained publishで安定稼働を確認し、その後にAOTを試すのが安全です。Native AOTは起動時間やメモリ使用量の面で利点がありますが、実行対象のランタイム環境を特定する必要があり、JITを使わない実行モデルになります。(Microsoft Learn)
CI/CDで確認すべき実務チェックリスト
Package Uploaderをリリースパイプラインに組み込んでいる場合は、次のチェックリストを順番に確認してください。
| チェック項目 | 確認方法 | NGだった場合の対処 |
|---|---|---|
| .NET 10 SDKが入っている | dotnet --list-sdks | SDKインストール、CIタスク更新 |
| 古いTargetFrameworkが残っていない | rg "net8.0" | net10.0へ更新し、依存パッケージを確認 |
System.CommandLine.Hosting参照がない | rg "System.CommandLine.Hosting" | System.CommandLine v2ベースへ移行 |
| lock fileで復元できる | dotnet restore --locked-mode | lock fileを更新し、NuGetソースを確認 |
| テストがCIで通る | dotnet test | MSTest.Sdk、実行環境、テストアダプターを確認 |
| publish成果物のパスが正しい | CIのartifactパス確認 | 新しいpublish出力先に修正 |
| 認証が通る | GetProductを実行 | tenant、secret、証明書、サービス接続を確認 |
| アップロードが通る | テストブランチで実行 | timeout、market group、パッケージ形式を確認 |
| ログが取得できる | -l指定やCIログ確認 | 保存先、権限、マスク対象情報を確認 |
| 失敗時の終了コードを拾える | 意図的に不正設定で実行 | パイプライン条件、エラーハンドリングを修正 |
CI/CDで特に多いのは、ビルド自体は成功しているのに、成果物パスの変更や認証情報の取り扱いで後続ステップが失敗するパターンです。移行作業では、restore → build → test → publish → smoke testの順に分けてログを残すと、問題箇所を特定しやすくなります。
社内手順書と開発者向けドキュメントも更新する
今回の更新は、コードだけでなくREADMEやdocsも更新対象です。つまり、社内の開発手順も.NET 10前提に直す必要があります。
特に更新したい箇所は次のとおりです。
- Package Uploaderの取得先と推奨バージョン
.NET 10 SDKのインストール手順publish.win-x64.ps1やLinux向けpublishスクリプトの実行手順- publish後の成果物パス
- CIで使うSDKバージョン
System.CommandLine.Hostingを使わないCLI実装方針- 認証方式ごとの設定例
GetProductによる疎通確認手順- 失敗時のログ取得方法
開発者が古い手順を見てnet8.0前提のコマンドを実行すると、環境差によるトラブルが増えます。移行後は「使えるコマンド」だけでなく、「使わない古い手順」も明確に削除してください。
今回の更新で次に取るべき行動
Microsoft developer platformのPackage Uploader更新は、.NET 8サポート終了を見据えた.NET 10移行と、非推奨のSystem.CommandLine.Hosting依存解消が中心です。実行ファイルを使うだけのユーザーは最新版への差し替えと簡単な動作確認で済む可能性が高い一方、ソースビルド、DLL組み込み、フォーク運用、CI/CD自動化をしているチームは、移行作業を計画的に進める必要があります。
まずは、利用箇所の棚卸し、.NET 10 SDKの確認、System.CommandLine.Hosting参照の検索、CIのrestore/build/test/publish確認から始めてください。そのうえで、GetProductやGetPackagesによる認証確認、テスト用ブランチでのアップロード確認、本番リリース手順の更新まで進めると、安全に.NET 10対応へ移行できます。
[5]: https://www.nuget.org/packages/System.CommandLine.Hosting/ “
NuGet Gallery
| System.CommandLine.Hosting 0.4.0-alpha.25306.1
“
[6]: https://learn.microsoft.com/ja-jp/dotnet/standard/commandline/migration-guide-2.0.0-beta5 “
System.CommandLine 2.0.0-beta5 以降への移行ガイド – .NET | Microsoft Learn”
コメント