.NET の「Packaging and Package Identity for .NET apps with WinApp CLI on Windows」は、Windows向け.NETデスクトップアプリにパッケージIDを付与し、MSIXパッケージ化までをWinApp CLIで扱いやすくする更新です。結論から言うと、既存アプリにただちに強制移行が発生する話ではありません。通知、バックグラウンドタスク、ファイル関連付け、共有ターゲット、Windows AI APIなど、パッケージIDが必要なWindows機能を使いたい.NETアプリ開発者・管理者が、今後のビルド、デバッグ、配布方法を見直すべき内容です。Microsoftは2026年6月29日の.NET Blogで、WinApp CLIによりdotnet runでパッケージID付き実行を試せること、winapp packでMSIXを作成しやすくなることを紹介しています。(Microsoft for Developers)
.NETアプリのPackaging and Package Identity更新ポイント
今回の更新で押さえるべき中心は、.NETアプリそのものの言語機能追加ではなく、Windows上で.NETデスクトップアプリを「OSに識別されるアプリ」として扱いやすくする点です。
これまで、WPF、WinForms、.NETコンソールアプリなどの「既定ではアンパッケージ」のアプリでWindowsの一部機能を使うには、マニフェスト、証明書、ビルド設定、MSIX関連作業を個別に理解する必要がありました。WinApp CLIは、この負担を減らし、ローカル実行時のパッケージID付与と、配布用MSIX作成をCLI中心で行えるようにします。(Microsoft for Developers)
特に重要な変更点は次の2つです。
| 確認項目 | 何ができるようになるか | 実務上の意味 |
|---|---|---|
dotnet runとの連携 | パッケージID付きで.NETアプリをローカル実行できる | 通知やWindows AI APIなど、ID必須機能を開発中に検証しやすい |
winapp pack | ビルド済みアプリをMSIXとしてパッケージ化できる | 配布、署名、Store申請、企業配布の検証がしやすい |
Package.appxmanifest生成 | アプリID、表示名、アセット、機能宣言を管理できる | Windowsとの統合点を明確にできる |
| 証明書コマンド | 開発用証明書の生成・インストールを支援 | ローカル検証時の署名作業を簡略化できる |
Package Identityとは何か
Package Identityは、Windowsがアプリを一意に識別するための情報です。単なるアプリ名ではなく、パッケージ名、バージョン、アーキテクチャ、リソースID、発行者などの組み合わせで構成されます。Microsoft Learnでは、Package Identityをパッケージを識別する論理的な構造として説明しています。(Microsoft Learn)
実務では、Package Identityを「Windowsに対するアプリの名刺」と考えると理解しやすくなります。Windowsがそのアプリを正しく識別できるため、次のようなOS連携機能を安全に扱えるようになります。
| 使いたい機能 | Package Identityが関係する理由 |
|---|---|
| トースト通知、プッシュ通知 | どのアプリが通知を出すかをWindowsが識別する必要がある |
| バックグラウンドタスク | アプリの登録情報と実行条件をOSが管理する |
| ファイル関連付け | 特定の拡張子をどのアプリで開くかを宣言する |
| 共有ターゲット | Windowsの共有UIにアプリを表示する |
| Windows AI API | OS機能の呼び出し元を識別する必要がある |
Microsoftのパッケージング概要では、MSIXでパッケージ化されたアプリはPackage Identityを持ち、多くのWindows拡張ポイントでPackage Identityが必要になると説明されています。アンパッケージアプリは自由度が高い一方、Package Identityを持たないため、これらの機能に制約が出ます。(Microsoft Learn)
影響範囲：対象になる.NETアプリとならないアプリ
今回の更新が特に関係するのは、Windowsデスクトップ向けの.NETアプリです。公式ブログでは、WinApp CLIは任意の.NETデスクトップフレームワークと互換性があると説明されています。(Microsoft for Developers)
| 対象 | 影響度 | 確認すべきこと |
|---|---|---|
| WPFアプリ | 高 | 通知、ファイル関連付け、MSIX配布を使う予定があるか |
| WinFormsアプリ | 高 | 既存インストーラーを維持するか、MSIXへ寄せるか |
| .NETコンソールアプリ | 中 | 実行エイリアスを設定しないと標準出力を確認しにくい場合がある |
| WinUI / Windows App SDK利用アプリ | 高 | 既存のWindows App SDK設定と競合しないか |
| ASP.NET Coreなどのサーバーアプリ | 低 | Windowsデスクトップ統合が目的でなければ通常は対象外 |
| 社内用の単純なEXE配布ツール | 中 | 将来、通知や自動更新、配布管理が必要になるか |
ここで重要なのは、「MSIXにするかどうか」と「Package Identityを持たせるかどうか」は近いが同じではない点です。Microsoft Learnでは、配布モデルとして、MSIXによるパッケージアプリ、既存インストーラーを維持しつつIDを付与する外部配置パッケージ、アンパッケージアプリが整理されています。既存のMSI/EXEインストーラーを完全に捨てずにPackage Identityを付与する選択肢もあります。(Microsoft Learn)
WinApp CLIで変わる開発フロー
WinApp CLIは、Windows SDK、パッケージング、アプリID、マニフェスト、証明書、ビルドツールを扱うためのCLIです。GitHub上の公式リポジトリではPublic Previewとして案内されており、開発中のツールである点は本番採用時に確認が必要です。(GitHub)
基本的な導入は、Windows Package Managerを使って行います。
winget install Microsoft.winappcli --source winget.NETプロジェクトでは、プロジェクトルートで初期化します。
winapp init . --use-defaultswinapp initは、Windows APIを使うために必要なTargetFrameworkの確認、必要なNuGet参照の追加、Package.appxmanifestとAssetsフォルダーの生成を行います。詳細な入力を制御したい場合は、--use-defaultsを外すことで、パッケージ名、発行者名、バージョンなどを指定できます。(Microsoft for Developers)
初期化後は、通常の.NETアプリと同じように実行します。
dotnet runプロジェクトにWinApp関連のNuGetパッケージが追加されている場合、dotnet run実行時にWinApp CLIが呼び出され、アプリがPackage Identity付きで起動します。これにより、Package Identityが必要なWindows機能をローカル開発中に検証できます。(Microsoft for Developers)
設定変更で確認すべきファイル
管理者やリード開発者は、WinApp CLIを試す前に、プロジェクトへどのような変更が入るかを把握しておくべきです。特に、CI/CDやコードレビューの対象になるファイルは事前に決めておくと安全です。
| ファイル・設定 | 変更内容 | 確認ポイント |
|---|---|---|
.csproj | Windows向けTargetFramework、NuGet参照、WinApp関連プロパティ | 既存のマルチターゲット構成と矛盾しないか |
Package.appxmanifest | アプリID、表示名、Publisher、Capabilitiesなど | 本番用Publisher名、権限宣言、表示名が正しいか |
Assetsフォルダー | MSIX用ロゴやタイル画像 | Store、社内配布、通知表示で違和感がないか |
| 証明書ファイル | 開発用または本番用署名証明書 | .pfxをリポジトリへ誤って含めないか |
| CI/CD定義 | winapp packや証明書処理の追加 | ランナーにWinApp CLIをどう導入するか |
dotnet runの自動連携を細かく制御したい場合は、.csprojにプロパティを追加します。たとえば、独自マニフェストの場所を指定したり、起動引数を渡したりできます。(Microsoft for Developers)
<PropertyGroup>
<WinAppManifestPath>$(MSBuildProjectDirectory)\custom\Package.appxmanifest</WinAppManifestPath>
<WinAppLaunchArgs>--debug --verbose</WinAppLaunchArgs>
</PropertyGroup>WinApp CLIによるdotnet run連携を止めたい場合は、次のように設定します。
<PropertyGroup>
<EnableWinAppRunSupport>false</EnableWinAppRunSupport>
</PropertyGroup>また、パッケージアプリとして実行しない構成に戻したい場合は、公式ブログで示されているようにWindowsPackageTypeをNoneに設定する方法もあります。(Microsoft for Developers)
<PropertyGroup>
<WindowsPackageType>None</WindowsPackageType>
</PropertyGroup>コンソールアプリで失敗しやすいポイント
.NETコンソールアプリでは、Package Identity付きで実行したときに、期待したターミナル出力が見えない場合があります。公式ガイドでは、コンソール出力を現在のターミナルに残すために、実行エイリアスをマニフェストへ追加し、.csproj側でエイリアス起動を有効化する手順が示されています。(GitHub)
winapp manifest add-alias<PropertyGroup>
<WinAppRunUseExecutionAlias>true</WinAppRunUseExecutionAlias>
</PropertyGroup>WPFやWinFormsのように自身のウィンドウを表示するアプリでは、この設定が不要な場合があります。一方、CLIツールや社内バッチ補助ツールをMSIX化する場合は、実行エイリアスの設計を先に決めておくべきです。エイリアス名が既存コマンドと衝突すると、ユーザー環境で混乱が起きます。
MSIXパッケージ化の基本手順
配布用のMSIXを作る場合は、Releaseビルド後にwinapp packを実行します。公式ブログでは、dotnet build -c Releaseでビルドし、出力フォルダーを指定してwinapp packを実行する流れが紹介されています。(Microsoft for Developers)
dotnet build -c Release
winapp pack .\bin\Release\net10.0-windows10.0.26100.0\win-x64ローカル検証では自己署名証明書を使うことがあります。
winapp cert generate --if-exists skip
winapp pack .\bin\Release\net10.0-windows10.0.26100.0 --manifest .\Package.appxmanifest --cert .\devcert.pfxただし、本番配布で自己署名証明書を安易に使うのは避けるべきです。Microsoft Learnでは、エンドユーザーの端末に登録するには、対象端末で信頼された証明書による署名が必要であり、自己署名証明書は開発目的に使うものとして説明されています。.pfxには秘密鍵が含まれるため、リポジトリや共有フォルダーに置かない運用が必要です。(Microsoft Learn)
Microsoft Storeに提出する場合、公式ガイドではStore側でMSIXに署名されるため、提出前に自前で署名する必要はないと説明されています。ただし、企業内配布、MDM配布、サイドローディングでは、組織の証明書ポリシーや信頼ストアの設計が必要です。(GitHub)
管理者が確認すべきポイント
WinApp CLIは開発者向けツールに見えますが、実際にはアプリ配布、証明書、端末管理、セキュリティレビューにも関係します。管理者は、次の観点で確認すると抜け漏れを減らせます。
| 観点 | 確認内容 | 判断基準 |
|---|---|---|
| ツールの成熟度 | WinApp CLIのバージョン、Public Previewであること | 本番ビルドへ入れる場合はバージョン固定と検証環境を用意する |
| 証明書 | 開発用と本番用を分離できているか | .pfxの保管場所、ローテーション、失効時の対応を決める |
| マニフェスト | Package Name、Publisher、Versionが正しいか | 更新時にVersionを上げる運用を作る |
| Capabilities | カメラ、マイク、場所などの権限宣言が必要最小限か | セキュリティレビューとプライバシー説明をセットで行う |
| 配布方式 | MSIX、Store、既存MSI/EXE、外部配置のどれにするか | 既存インストーラーを維持する必要があるかで判断する |
| アーキテクチャ | x64、Arm64をどう扱うか | 複数アーキテクチャ配布ではMSIX bundleや個別ビルドを検討する |
| CI/CD | ビルドエージェントにWinApp CLIを導入できるか | GitHub ActionsやAzure DevOpsで再現性を確保する |
特に見落としやすいのが、マニフェストのバージョン管理です。公式ガイドでは、再パッケージ化して更新する場合、Package.appxmanifestのVersionを上げる必要があると説明されています。更新番号を上げ忘れると、ユーザー端末で新しいパッケージとして認識されず、検証が止まる原因になります。(GitHub)
既存アプリは移行すべきか
今回の更新だけを理由に、すべての既存.NETデスクトップアプリをMSIX化する必要はありません。判断基準は「Windows統合機能を使うか」「配布と更新をどう管理したいか」です。
| 状況 | 推奨判断 |
|---|---|
| 通知、ファイル関連付け、共有ターゲット、Windows AI APIを使う予定がある | Package Identity付与を検証する |
| Microsoft StoreやMDMで配布したい | MSIXパッケージ化を優先的に検証する |
| 既存のMSI/EXEインストーラーを維持したい | 外部配置パッケージや段階導入を検討する |
| 単純な社内ツールでWindows統合が不要 | すぐに移行しなくてもよい |
| 証明書管理や配布基盤が未整備 | 先に署名・配布・更新ルールを整備する |
外部配置パッケージは、既存のインストール場所や更新方法を変えずにPackage Identityを付与する軽量な選択肢として説明されています。既存の大規模なWin32/WPF/WinFormsアプリでは、いきなりMSIXへ全面移行するより、まずPackage Identityが必要な機能だけを検証するほうが現実的です。(Microsoft Learn)
移行期限とサポート期限の考え方
公式ブログの今回の記事では、WinApp CLI対応に関する強制移行期限は示されていません。そのため、移行計画は「機能要件」と「.NETランタイムのサポート期限」を分けて考える必要があります。
| 項目 | 期限・扱い | 対応 |
|---|---|---|
| WinApp CLIによるPackage Identity対応 | 強制移行期限は示されていない | 必要なWindows機能があるアプリから検証する |
| .NET 8 | 2026年11月10日サポート終了 | 継続運用アプリは.NET 10などサポート対象版への移行計画を作る |
| .NET 9 | 2026年11月10日サポート終了 | STS利用中のアプリは期限前に移行する |
| .NET 10 | 2028年11月14日までサポート対象 | 新規のWindowsデスクトップアプリでは有力な候補になる |
Microsoftの公式サポートポリシーでは、.NET 8と.NET 9のサポート終了は2026年11月10日、.NET 10のサポート終了は2028年11月14日とされています。WinApp CLIを試すタイミングでTargetFrameworkを見直すなら、Package Identity対応と.NETバージョン更新を同じ検証計画に入れると効率的です。(Microsoft)
グローバル配布で注意すべき点
グローバル向けに.NETデスクトップアプリを配布する場合、Package Identity対応は単なるビルド設定では終わりません。国や地域をまたぐ配布では、表示名、発行者名、ロゴ、権限説明、証明書、更新経路を統一しておく必要があります。
特に、カメラ、マイク、位置情報などの機能を使うアプリでは、Windowsのプライバシー設定や同意プロンプトにアプリ情報が表示される場合があります。Microsoft Learnでは、Package Identityを理解する機能により、Windows側のUIにマニフェストの文字列や画像が表示されることがあると説明されています。(Microsoft Learn)
グローバル配布で最低限確認したい項目は次のとおりです。
| 項目 | 確認ポイント |
|---|---|
| Publisher名 | 証明書のSubjectとPackage.appxmanifestのPublisherが整合しているか |
| 表示名 | 日本語、英語、その他対象言語で誤解がないか |
| ロゴ | Windows通知、スタートメニュー、Store表示で崩れないか |
| Capabilities | 各地域のプライバシー要件に照らして過剰でないか |
| 更新経路 | Store、MSIX配布、既存インストーラーのどれを正式経路にするか |
| サポート窓口 | パッケージ名やPackage Family Nameを問い合わせ対応で確認できるか |
導入時によくある失敗と対策
| 失敗しやすいポイント | 原因 | 対策 |
|---|---|---|
dotnet runで想定どおりID付き実行にならない | Windows向けTargetFrameworkでない、マニフェストが見つからない | WinAppManifestPathとTargetFrameworkを確認する |
| コンソール出力が見えない | AUMID起動により別ウィンドウで実行される | winapp manifest add-aliasとWinAppRunUseExecutionAliasを使う |
| MSIX更新が入らない | パッケージVersionを上げ忘れている | リリース時にVersion更新をCIで検査する |
| 証明書エラーになる | 自己署名証明書が信頼ストアに入っていない | 開発用証明書をTrusted Peopleへ登録する |
| 複数EXEでパッケージ化に失敗する | winapp packが実行ファイルを特定できない | --executableで対象EXEを明示する |
| 本番ビルドが再現できない | WinApp CLIやSDKのバージョンが固定されていない | ツールバージョン、SDK、ランナーイメージを固定する |
| 権限レビューで差し戻される | Capabilitiesを必要以上に宣言している | 使う機能とマニフェスト宣言を対応表で管理する |
winapp packは、対象フォルダーに複数の.exeがある場合など、実行ファイルを自動判定できないケースでは--executableの指定が必要になります。CI/CDで安定してパッケージ化するなら、自動判定に頼りすぎず、明示的な指定を入れるほうが安全です。(GitHub)
まず何から確認すべきか
今回の.NET向けPackaging and Package Identity更新は、Windowsデスクトップアプリの「開発中の検証」と「配布準備」をつなぐ実務的な改善です。すぐに全アプリを移行するのではなく、次の順で確認すると無理なく進められます。
- 対象アプリがWindowsのPackage Identity必須機能を使う予定があるか確認する
.NET 8または.NET 9を使っている場合は、2026年11月10日のサポート終了を踏まえてTargetFramework更新も検討する- 開発環境で
winapp initとdotnet runを試し、Package Identity付き実行で必要機能が動くか確認する Package.appxmanifest、証明書、Capabilities、バージョン更新ルールをレビューする- 配布方式をMSIX、Store、既存MSI/EXE維持、外部配置のどれにするか決める
管理者にとって最も大切なのは、WinApp CLIを「便利な開発コマンド」としてだけ扱わないことです。Package Identityは、通知、権限、ファイル関連付け、証明書、配布方式に関わります。まずは1つの検証用.NETデスクトップアプリで、winapp init、dotnet run、winapp pack、証明書インストール、更新バージョン管理までを一通り試し、自社のビルド・配布ルールに落とし込むところから始めるのが現実的です。
コメント