MSIX ストア提出前テストガイド:パッケージの問題を認証前に見つけよう
2026-06-01
Tags: Windows · Microsoft Store · MSIX · ストアの落とし穴
ストアの落とし穴 #4では、.NET トリミングが WinUI 3 の機能を黙って壊す問題に遭遇しました——ローカルの Debug ビルドでは問題なく動作していたのに、Release パッケージを提出するとリジェクトされました。こうした問題に共通するのは、提出前にローカルでパッケージ済みの成果物を検証していれば、多くの問題に事前に気付けたということです。もちろん、すべての問題を事前に発見できるわけではありません(例えば、依存パッケージによるゴーストスタートメニューエントリはローカルでの再現が困難です)が、少なくとも大部分の問題は防げます。
この記事では、Store 提出前の MSIX パッケージのローカル検証ワークフローをまとめます。WACK 認定、自己署名証明書のインストール、依存関係のインストール、クリーンな VM でのテストを網羅しています。
ステップ 1:WACK(Windows アプリ認定キット)を実行する
WACK は、Microsoft が提供するローカル事前認定ツールです。パッケージに対して一連のチェックを実行し、Store 認定の一部のテストをシミュレートします。
重要なポイント:
- Release ビルドでのみ検証可能で、Debug ビルドには対応していません——これにより、必然的に Release 構成でテストすることになります
- WACK は Microsoft によって非推奨とマークされています(メンテナンス終了)が、オプションのローカル事前チェックとして引き続き使用可能です。正式な認定は Store への提出後に自動的に実行されます
- WACK に合格しても Store 認定の通過を保証するものではありませんが、基本的な問題(API コンプライアンス、パフォーマンス、セキュリティなど)の多くを発見するのに役立ちます
使い方:Visual Studio の「パッケージと発行」ウィザードで、「パッケージの選択と構成」ステップの下部にある「Windows アプリ認定キットを使用してアプリを検証するためにプロジェクトをビルドする」オプションにチェックを入れます。パッケージ化が完了すると、「Windows アプリ認定キットの起動」ボタンが表示されます。または、スタートメニューで Windows App Certification Kit を検索して手動で起動することもできます。
ステップ 2:自己署名証明書付きのテストパッケージを作成する
この手順は少し複雑です。
MSIX パッケージは署名されていないとインストールできません。開発中、Visual Studio は一時証明書を使用しますが、生成された MSIX パッケージ自体には使用可能な証明書が含まれていない場合があります。実際のワークフローは以下の通りです:
まずサイドローディングモードでパッケージ化する
- プロジェクトを右クリック → パッケージと発行
- サイドローディングを選択(Microsoft Store は選択しない)
- 署名証明書を選択してパッケージ化を完了
次に Store モードでテストパッケージを作成する
- 再度 パッケージと発行 を実行し、今度は Microsoft Store(PublisherName による AppName) を選択
- これで生成されるテストパッケージ(
AppPackagesディレクトリ下の_Testフォルダー)に自己署名証明書が含まれるようになります
手順 1〜3 をスキップして直接 Store パッケージを作成すると、MSIX の証明書が空になります——かなり厄介な落とし穴です。
ステップ 3:証明書をインストールする
証明書付きのテストパッケージを入手したら:
証明書のインストール
.msixファイルを右クリック → プロパティ → デジタル署名 タブ- 署名を選択 → 詳細 → 証明書の表示
- 証明書のインストール → ローカル コンピューター を選択 → 信頼されたユーザー(Trusted People) ストアに配置
注意:証明書の Publisher(CN)は Package.appxmanifest の <Publisher> と一致している必要があります。一致しない場合、インストールは失敗します。
ステップ 4:依存関係と MSIX パッケージをインストールする
Windows App SDK プロジェクトが framework-dependent モード(デフォルト)の場合、アプリの実行には Windows App Runtime が必要です。Store 配布では依存関係が自動的に処理されますが、ローカルテストでは手動でインストールする必要があります。
幸いなことに、テストパッケージの _Test フォルダーには Dependencies サブディレクトリが含まれており、アーキテクチャごとに依存パッケージが整理されています:
AppPackages/
MyApp_1.0.0.0_x64_Test/
Dependencies/
x64/
Microsoft.WindowsAppRuntime.1.8.msix
...
MyApp_1.0.0.0_x64.msixインストール順序:まず Dependencies 内のランタイムをインストールし、その後アプリ本体をインストールします。
self-contained モード(.csproj で <WindowsAppSDKSelfContained>true</WindowsAppSDKSelfContained> を設定)を使用している場合、追加の依存関係のインストールは不要です。ランタイムは既にアプリにバンドルされています。
ステップ 5:クリーンな VM で全プロセスを検証する
開発マシンには各種 SDK、ランタイム、キャッシュがインストールされています——あなたのアプリがそこで動いても、ユーザーの環境で動くとは限りません。クリーンな環境で全ワークフローを検証することを強くお勧めします。
VM の選択肢
どちらでも構いません:
- Hyper-V Quick Create:Microsoft 推奨の方法。スタートメニューで「Hyper-V Quick Create」を検索し、MSIX Packaging Tool Environment を選択して VM を作成
- VMware:私が実際に使用している方法。クリーンな Windows 10/11 VM を作成し、スナップショットを取得して、テストのたびにクリーンな状態に復元
どちらを選ぶにせよ、核心となる要件は一つだけ:ユーザーの初回インストール環境にできるだけ近づけること。
クリーンな VM で検証する項目
- 自己署名証明書をインストール(ステップ 3 の手順)
- 依存パッケージをインストール(ステップ 4)
- アプリ本体をインストール
- アプリを起動し、コア機能が正常に動作することを確認
- スタートメニュー、タスクバーのトレイ、アンインストールなどが正常に機能することを確認
チェックリスト
Store に提出する前に、このチェックリストに沿って確認してください:
- [ ] Release 構成でテストパッケージを作成
- [ ] WACK を実行し、重大なエラーがないことを確認
- [ ] テストパッケージに自己署名証明書が含まれていることを確認(先にサイドローディングモードでパッケージを作成)
- [ ] 証明書を Local Machine → Trusted People にインストール
- [ ] クリーンな VM で全プロセスを検証:証明書のインストール → 依存関係のインストール → アプリのインストール → 機能テスト
- [ ] framework-dependent モードで依存パッケージが正常にインストールされることを確認
- [ ] アプリが正常に起動し、コア機能が利用可能、スタートメニュー/アンインストールが正常に動作
この記事はストアの落とし穴シリーズの補足記事です。