MENU

VS 2022 ARM版でMSIXをMicrosoft Storeに公開する方法｜WAPPが見つからない問題の完全解決ガイド

Visual Studio

VS 2019 の Windows Application Packaging Project（WAPP）で Microsoft Store へ直接発行していたワークフローを、VS 2022（ARM 版）へ移行したら「WAPP テンプレートが見当たらず公開できない」——そんなつまずきを、最短経路で解決するための実践ガイドです。結論は、単一プロジェクト方式の MSIX パッケージングへ移行し、必要に応じて MSIX Packaging Tool を併用すること。移行の背景、手順、CLI、自動化、証明書、トラブル対応まで一気通貫で整理します。

目次

問題の全体像と背景

VS 2019 では WAPP（Windows Application Packaging Project）という 専用の「パッケージング用サブプロジェクト」 を追加し、そこで MSIX を生成・署名・発行するのが定番でした。VS 2022（特に ARM 版）では WAPP テンプレートが既定で見つからない、または環境によってサポート状況が変わるため、従来フローのままでは Microsoft Store への提出が止まります。

Microsoft は近年、Single‑project MSIX（単一プロジェクト方式）を推奨しています。これはアプリ本体プロジェクトに MSIX 機能を直接組み込み、WAPP のような別プロジェクトを不要とする方式です。VS 2022 ではこの方向性に合わせて、拡張機能経由のワークフローが中心となりました。

結論（最短解）

  • Single‑project MSIX Packaging Tools（VS 拡張機能）を導入し、アプリ本体プロジェクトから MSIX を生成・発行します。
  • 複数 EXE を束ねるなど 従来型 WAPP が必要な場合は、MSIX Packaging Tools（VS 拡張機能）またはMSIX Packaging Tool（スタンドアロン）で補完します。
  • ARM 版 VS 2022 でも拡張機能は動作します。署名用 PFX と「パッケージ ID 名称」をストア登録内容と一致させてください。

課題と解決策の対応表

課題解決策補足ポイント
WAPP テンプレートが VS 2022 には標準搭載されていないSingle‑project MSIX Packaging Tools をインストールし、既存のアプリ プロジェクトから単一プロジェクト方式で MSIX を生成VS の「拡張機能 > オンライン」で “Single‑project MSIX” を検索
複数実行ファイルなどで従来型 WAPP が必要MSIX Packaging Tools（VS 拡張）を追加、またはMSIX Packaging Tool（アプリ）でパッケージ化・署名スタンドアロン版は OS に付属の MSIX ツール群と併用可能
ARM 版 VS 2022 でのデバッグ／署名拡張機能は ARM でも動作。PFX の発行者情報とストアの「パッケージ ID」を一致させるアップロード前に「パッケージ検証」を必ず実施
参考リンクの遷移やドキュメントの世代交代拡張機能は VS マーケットプレース、解説は公式ドキュメントを都度検索して最新を参照画面名称やオプションが小刻みに更新される点に注意

初期セットアップ（ARM 版 VS 2022）

まずは不足コンポーネントを埋め、パッケージングの前提を整えます。

項目推奨設定理由
VS ワークロード.NET デスクトップ開発＋ユニバーサル Windows プラットフォーム開発MSIX ツールやサンプル テンプレートの依存関係を満たす
VS 拡張機能Single‑project MSIX Packaging Tools（必須）
必要に応じて MSIX Packaging Tools		単一プロジェクト方式の UI とビルド統合が有効化される
証明書ストア提出用の PFX（SHA-256）Publisher 名がストア登録の「パッケージ ID 名称」と一致している必要

Single‑project MSIX での発行フロー（GUI）

  1. VS 2022（ARM）でアプリ プロジェクトを開き、拡張機能のインストール後にプロジェクトの [プロパティ] → [パッケージ化] を開く。
  2. アプリ識別子（Identity）、パッケージ表示名、バージョン、署名証明書（PFX） を設定。
  3. 必要なら App Installer（自動更新）を有効化し、更新頻度や配布 URL 置換子を設定。
  4. [発行] → [Microsoft Store] を選択し、Release/ARM64 などターゲットを指定してビルド。
  5. 生成された .msix または .msixbundle を パートナー センターの申請でアップロード。

csproj の最小構成例（単一プロジェクト方式）

GUI で設定しても内部的にはプロジェクト ファイルにプロパティが書き込まれます。以下はシンプルな例です。

<PropertyGroup>
  <TargetFramework>net8.0-windows10.0.19041.0</TargetFramework>
  <OutputType>WinExe</OutputType>


true
MSIX


true


true
OnApplicationRun


true
THUMBPRINT_HERE
$(OutDir)MSIX</AppxPackageDir>

注: プロパティ名や既定値は拡張機能や SDK バージョンによって若干の差異があります。VS のプロパティ ページから設定すれば正しい値が入ります。

既存 WAPP から単一プロジェクトへ移行する手順

  1. VS 2019 の WAPP プロジェクトで パッケージ マニフェスト（Package.appxmanifest） を開き、Identity（Name, Publisher） と アプリケーション エントリ を確認・控える。
  2. VS 2022 プロジェクトに Single‑project MSIX を有効化し、Identity を同一値で再設定（Name と Publisher が一致しないとストアで継続配布扱いにならない）。
  3. 必要な 宣言（Capabilities, File Type Associations, Protocol） を csproj／manifest の編集画面から反映。
  4. Assets（ロゴ、スプラッシュ、タイル） を新プロジェクトにコピーし、サイズ要件を満たすよう差し替え。
  5. WAPP 固有の アプリケーション修飾子や 処理手順がある場合は、AppxManifest.xml 相当の編集で再現。

Identity と署名（最重要）

ストア継続配布には Identity の完全一致が必須です。典型的には以下のようになります。

&lt;Identity
  Name="YourCompany.YourApp"
  Publisher="CN=YOUR-PUBLISHER-DISTINGUISHED-NAME"
  Version="1.2.3.0" /&gt;
  • Publisher は PFX の発行者名と一致していること。
  • バージョンは Major.Minor.Build.Revision の 4 要素。ストア提出時は既存より 上げる必要があります。
  • 証明書の有効期限・鍵サイズ・ハッシュ アルゴリズム（SHA-256）に注意。

Microsoft Store への提出フロー（Partner Center）

  1. Partner Center でアプリを選択し、新規申請を開始。
  2. パッケージに .msix または .msixbundle をアップロード。
  3. デバイス ファミリ、アーキテクチャ、最小バージョン などのターゲットを確認。ARM64 を配布したい場合は ARM64 バリアントを必ず含める。
  4. 年齢レーティング、ストア リスト（説明文、スクリーンショット、検索キーワード）を更新。
  5. 自動テスト・審査が通れば公開。

ARM64 バリアントを含める理由とコツ

  • ARM デバイスは x64 エミュレーションでも動くものの、ARM64 ネイティブを提供すると起動・消費電力・メモリで有利。
  • プロジェクトの構成に ARM64 を追加し、Any CPU の条件付き依存を避ける。
  • ネイティブコード混在（C++/CLI、P/Invoke）の場合は ARM64 用バイナリを用意し、ロード パスを確認。

MSIX Packaging Tool（スタンドアロン）の有効な使い所

GUI ベースで 既存 EXE/MSI から MSIX へ変換でき、複数 EXE を 1 パッケージに束ねたいケースでとても便利です。主な使い方は次の通りです。

  1. 対象アプリを 監視インストールし、レジストリ・ファイル変更をキャプチャ。
  2. ショートカット、プロトコル、ファイル関連付けを GUI で定義。
  3. 生成された .msix を signtool で署名し、Store 提出または社内配布に利用。

単一プロジェクト方式と併用し、「VS で作る本体」＋「ツール群を外側から同梱」のような構成にも対応できます。

CLI による自動化（MSBuild / MakeAppx / Signtool）

CI/CD で再現性の高いパッケージを作るには CLI が有効です。代表例を載せます。

MSBuild でビルドからバンドル作成まで

msbuild .\MyApp.csproj ^
  /t:Restore,Rebuild ^
  /p:Configuration=Release ^
  /p:Platform=arm64 ^
  /p:GenerateAppxPackageOnBuild=true ^
  /p:AppxBundle=Always ^
  /p:AppxBundlePlatforms="x86|x64|arm64" ^
  /p:AppxPackageDir="$(Build.ArtifactStagingDirectory)\Appx\"

ヒント: UWP/デスクトップブリッジ互換のプロパティ（例: UapAppxPackageBuildMode=StoreUpload）を併用する環境もあります。プロジェクトの種類と SDK に合わせて調整してください。

MakeAppx / SignTool を直接使う場合

rem フォルダーから MSIX を生成
makeappx pack /d ".\AppFiles" /p ".\MyApp_1.2.3.0_x64.msix"

rem 複数アーキテクチャを束ねてバンドル化
makeappx bundle /d ".\BundlesRoot" /p ".\MyApp_1.2.3.0.msixbundle"

rem 署名（PFX を使用）
signtool sign /fd SHA256 /a /f ".\StoreSigningCert.pfx" /p "yourpassword" ".\MyApp_1.2.3.0.msixbundle"

App Installer（自動更新）の最小例

社内配布や段階的リリースで便利な App Installer のスニペットです。

&lt;AppInstaller Uri="https://contoso.example/MyApp.appinstaller"
              Version="1.2.3.0"
              xmlns="http://schemas.microsoft.com/appx/appinstaller/2018"&gt;
  &lt;MainPackage Uri="https://contoso.example/MyApp_1.2.3.0.msixbundle"
               Version="1.2.3.0"
               Publisher="CN=YOUR-PUBLISHER" /&gt;
  &lt;UpdateSettings&gt;
    &lt;OnLaunch HoursBetweenUpdateChecks="0" /&gt;
  &lt;/UpdateSettings&gt;
&lt;/AppInstaller&gt;

よくあるエラーと対処

症状原因対処
「パッケージ ID 名称が一致しない」Identity.Name / Publisher がストア登録と異なるWAPP 時代の値を流用し、Publisher は PFX の発行者と完全一致に
「この証明書では署名できない」期限切れ／SHA-1／鍵長不足SHA-256・十分な鍵長の証明書で更新。タイムスタンプも付与
ARM64 だけ起動しないネイティブ依存（DLL）が ARM64 未対応ネイティブ資産を ARM64 でビルドし、MSIX のアーキごとに正しい DLL を梱包
パッケージ検証で失敗宣言不足・能力（Capabilities）不整合機能使用箇所を棚卸しし、manifest の宣言・制限条項を整理
既定アプリ化・関連付けが効かないFileTypeAssociation/Protocol の宣言不備拡張子・ProgID・動作を manifest に明示。OS 側の既定選択も確認
アップロード後にクラッシュが増えた符号化・最適化設定の差、アーキテクチャ差異Store の診断を確認、シンボル登録しクラッシュ解析。構成別に A/B 配布

検証のベストプラクティス

  • パッケージ検証（VS または Windows App Certification Kit）を提出前に必ず実行。
  • インプレース更新とクリーン インストールの両方を ARM64 / x64 でテスト。
  • ファイル/レジストリのリダイレクト（仮想化）を理解し、書き込み先の衝突を防止。
  • UWP API / Win32 API の混在では 権限と宣言の境界を再確認。

複数 EXE をまとめる場合の設計パターン

WAPP 相当の構成が必要でも、次のパターンで単一プロジェクト方式に寄せられます。

  1. メイン EXE を起点に他 EXE をコンテンツとして同梱し、起動はコマンドラインで行う。
  2. どうしても「複数ショートカット」を定義したい場合は、MSIX Packaging Toolの GUI で Applications を複数登録。
  3. メンテナンス性と Store ポリシー準拠の観点から、可能なら単一 EXE に統合を検討。

セキュリティとプライバシー

  • MSIX はファイルシステム/レジストリ仮想化により、クリーンなアンインストールと差分更新が可能。
  • 権限は最小限で宣言し、機微なデータや ネットワーク権限はレビューの対象。
  • 証明書の保護（秘密鍵の分離、セキュアなビルド代理署名）を徹底。

ビルドの再現性と CI/CD 例（概略）

GitHub Actions 例（概略）です。ARM64 ホストでも動作する自己完結フローを組みます。

name: Build-MSIX
on: { push: { branches: [ main ] } }
jobs:
  build:
    runs-on: windows-latest
    steps:
      - uses: actions/checkout@v4
      - name: Setup MSBuild
        uses: microsoft/setup-msbuild@v2
      - name: Restore &amp; Build
        run: |
          msbuild .\MyApp.csproj /t:Restore,Rebuild /p:Configuration=Release ^
            /p:Platform=arm64 /p:GenerateAppxPackageOnBuild=true ^
            /p:AppxBundle=Always /p:AppxBundlePlatforms="x86|x64|arm64"
      - name: Sign bundle
        run: |
          signtool sign /fd SHA256 /a /f .\certs\Store.pfx /p $env:SIGN_PWD `
            ".\bin\Release\MSIX\MyApp_*.msixbundle"
      - name: Artifact
        uses: actions/upload-artifact@v4
        with: { name: msix, path: bin\Release\MSIX\*.msix* }

チェックリスト（提出直前）

  • Identity（Name/Publisher）が 旧 WAPP と一致している。
  • AppxBundle に x86/x64/arm64 が含まれる（対象に応じて最適化）。
  • PFX の秘密鍵保護・パスワード管理・有効期限を確認。
  • ビルド番号をインクリメントし、App Installer の参照先を更新。
  • 「パッケージ検証」を行い、ダッシュボードの自動テスト結果が緑である。

FAQ

Q. VS 2022（ARM）で WAPP をどうしても使いたい
A. 環境によってはテンプレートが出ないか、サポートが限定的です。Single‑project MSIXへの移行が最短です。複雑な束ね方が必要な場合は MSIX Packaging Tool を併用してください。

Q. Publisher を変えたい
A. 別アプリ扱いになります。既存ユーザーの自動更新やストア内継続性が切れるため、既存アプリの継続配布では 同一 Publisher を維持してください。

Q. ARM64EC を使うときの注意は？
A. ネイティブ DLL 群のロード順序や混在アーキテクチャに注意。バリアントごとに正しいネイティブ資産が梱包されているかを実機で確認します。

Q. ストア外にも配りたい
A. App Installer を併用すれば、社内配布＋自動更新が実現可能です。証明書の信頼性（社内ルート配布など）を担保してください。

まとめ

VS 2019 時代の WAPP 前提のフローは、VS 2022（ARM 版）ではそのまま持ち込めない場面があります。Single‑project MSIXへ移行し、必要に応じて MSIX Packaging Toolを併用することで、MSIX の生成・署名・検証・提出までを ARM 環境でも安定運用できます。Identity と証明書整合性、ARM64 バリアントの同梱、提出前検証の徹底——この三点を押さえれば、Microsoft Store への公開は確実に前進します。

付録：移行時の差分早見表（WAPP → 単一プロジェクト）

観点WAPP（VS 2019）Single‑project MSIX（VS 2022）対応のヒント
プロジェクト構成別プロジェクト（Packaging）を追加アプリ本体に MSIX 機能を内蔵csproj のプロパティで切り替え
複数 EXEApplications を複数定義しやすい基本は 1 本、複数は工夫が必要MSIX Packaging Tool で補完
署名WAPP 側で一括定義本体プロジェクト側に記載PFX・Publisher を継承
発行 UIWAPP から Store 送信本体プロジェクトの [発行]拡張機能の UI を使用
自動更新App Installer を追加設定プロパティから容易に有効化更新頻度は OnLaunch 等

次にやること（アクションプラン）

  1. VS 2022（ARM）で Single‑project MSIX Packaging Tools を導入。
  2. アプリ プロジェクトの [パッケージ化]タブで Identity と PFX を設定。
  3. ARM64 ターゲットを追加し、Release ビルドで パッケージ検証を実行。
  4. Partner Center へ .msixbundle をアップロードし、申請を完了。
Visual Studio
パッケージング Microsoft Store Visual Studio 2022 Windows App SDK ARM64 MSIX

この記事を書いた人

佐藤健司のアバター 佐藤健司

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

関連記事

コメント

コメントする

目次