WinApp v0.2ビジュアルエディターの使い方|AppxManifestのXMLミスをビルド前に防ぐ

AppxManifest.xmlを手作業で編集していると、名前空間の指定漏れ、Publisherの形式不備、バージョン番号の桁不足、ロゴ画像のパスやサイズの誤りに気付かないまま作業が進み、MSIXパッケージの作成時に初めてエラーになることがあります。

WinApp VS Code拡張のv0.2では、AppxManifest.xmlをフォーム形式で編集できるビジュアルエディターが追加されました。ファイルを右クリックして「Open With…」から開けば、入力内容をリアルタイムで検証できます。さらに「Regenerate Assets」を使うと、1枚の元画像から必要なアプリアセットを生成できます。編集結果は既存のコメントや空白、属性順を保ちながら元のXMLへ反映されます。(Microsoft for Developers)

この記事では、WinApp v0.2ビジュアルエディターの導入方法、開き方、各タブの使い分け、リアルタイム検証の見方、アセット生成の手順を実務向けに解説します。

目次

WinApp v0.2ビジュアルエディターとは

WinAppは、Windows App Development CLIをVS Codeから利用できるようにするMicrosoft提供の拡張機能です。Windowsアプリの初期化、実行、デバッグ、MSIXパッケージ作成、証明書生成、署名などをVS Code内から操作できます。

Microsoftが2026年7月20日に発表したv0.2では、AppxManifest.xmlおよび拡張子が.appxmanifestのファイルをフォーム形式で編集できる「AppxManifest Editor」が追加されました。(Microsoft for Developers)

ビジュアルエディターには、次のタブがあります。

タブ主に編集できる内容
Identityパッケージ名、Publisher、Version、CPUアーキテクチャ、Resource ID
Properties表示名、発行元表示名、説明、ストアロゴ
Dependencies対象デバイスファミリ、最小OSバージョン、パッケージ依存関係
Resourcesja-JPなどのBCP-47言語タグ
Capabilitiesインターネット、マイク、制限付き機能、デバイス機能
Applications実行ファイル、エントリーポイント、信頼レベル、ロゴ、タイル、拡張機能

Applicationsでは、プロトコルアクティベーション、COM Server、バックグラウンドタスク、ファイルの関連付け、App Service、実行エイリアス、スタートアップタスクなども追加できます。依存関係やリソースは並べ替えられ、XMLに出力される順序を調整できます。([marketplace.visualstudio.com][2])

WinApp v0.2の利用条件

利用前に、OSとVS Codeのバージョンを確認してください。

項目必要条件
OSWindows 10以降
VS Code1.109.0以降
拡張機能WinApp v0.2以降
対象ファイルAppxManifest.xmlまたは*.appxmanifest
WinApp CLI拡張機能に同梱されるため、原則として別途インストール不要

デバッグする場合は、使用言語に対応するデバッガー拡張も必要です。C#や.NETではC#用デバッガー、C/C++ではC/C++拡張、ElectronではVS Code内蔵のNode.jsデバッガーを利用します。マニフェストの編集だけであれば、デバッガー拡張は必須ではありません。([marketplace.visualstudio.com][2])

なお、WinApp拡張とWinApp CLIはPublic Previewです。業務プロジェクトで使う場合は、編集前のコミットを残し、拡張機能を更新した後は既存プロジェクトで動作確認してから展開するのが安全です。([marketplace.visualstudio.com][2])

WinApp拡張をインストールする方法

VS Codeからインストールする手順は次のとおりです。

  1. VS Codeを起動します。
  2. CtrlShiftXを押して拡張機能ビューを開きます。
  3. 検索欄に「WinApp」と入力します。
  4. Microsoft提供のWinApp拡張を選択します。
  5. 「Install」をクリックします。
  6. インストール後、必要に応じてVS Codeを再読み込みします。

コマンドラインからインストールする場合は、次のコマンドを使用します。

code --install-extension Microsoft-WinAppCLI.winapp

拡張機能の詳細画面に古いバージョンが表示されている場合は、更新を実行してv0.2以降にしてください。公式のインストール手順でも、拡張機能ビューから「WinApp」を検索する方法と上記コマンドが案内されています。(Microsoft for Developers)

AppxManifest Editorを開く手順

WinAppのビジュアルエディターは、通常のXMLエディターとは別のエディターとして登録されます。

  1. VS CodeでWindowsアプリのプロジェクトフォルダーを開きます。
  2. エクスプローラーからAppxManifest.xmlまたは.appxmanifestファイルを探します。
  3. 対象ファイルを右クリックします。
  4. 「Open With…」を選択します。
  5. 一覧から「AppxManifest Editor」を選択します。

ファイルを通常どおりダブルクリックしたときにXMLが表示されても、拡張機能の故障とは限りません。右クリックして「Open With…」を選び直してください。

ビジュアルエディターからXMLを直接確認したくなった場合も、同じ「Open With…」から標準のテキストエディターへ切り替えられます。WinAppではビジュアルエディターが任意選択のエディターとして登録されており、元のXMLへいつでも戻れる設計です。(GitHub)

Identityタブでパッケージ識別情報を設定する

最初に確認したいのがIdentityタブです。ここに誤りがあると、パッケージ作成、署名、更新、インストールの各工程で問題が発生します。

項目入力例確認ポイント
NameContoso.SampleApp予約済みのパッケージ名や既存パッケージと一致させる
PublisherCN=Contoso, O=Contoso LtdX.500識別名の形式で入力する
Version1.2.0.0Major.Minor.Build.Revisionの4区切りにする
Processor Architecturex64ビルド対象のアーキテクチャと合わせる
Resource ID必要な場合のみ入力通常の単一パッケージでは空欄になることもある

Publisherは証明書のSubjectと一致させる

ビジュアルエディターは、PublisherがX.500識別名として正しい形式かを検証します。ただし、形式が正しいことと、署名証明書のSubjectに一致していることは別問題です。

たとえば、次の値は形式としては成立します。

CN=Contoso, O=Contoso Ltd

しかし、実際の署名証明書のSubjectが次のようになっていれば一致しません。

CN=Contoso Software, O=Contoso Ltd, C=JP

Publisherには、証明書のSubjectを省略せず、そのまま設定してください。Microsoftのマニフェスト仕様でも、Publisher属性はパッケージの署名に使用する証明書のSubject情報と一致する必要があるとされています。(Microsoft Learn)

Versionは必ず4区切りにする

次のような値はエラーになります。

1.0
1.2.3
v1.2.3.4

正しくは、次のように4つの数値をピリオドで区切ります。

1.0.0.0
1.2.3.4

各要素に設定できる値は0から65535までです。WinAppのビジュアルエディターは、4区切りになっているか、各値が範囲内かをリアルタイムで確認します。(GitHub)

PropertiesとResourcesを設定する

Propertiesタブでは、ユーザーに表示される情報を設定します。

主な項目は次のとおりです。

  • Display Name
  • Publisher Display Name
  • Description
  • Store Logo
  • パッケージ種別に関するプロパティ

Display NameとPublisher Display Nameは、IdentityのNamePublisherとは役割が異なります。IdentityはWindowsがパッケージを識別するための値であり、Display Nameはユーザーに見せる名称です。

たとえば、IdentityのNameを次のように設定していても問題ありません。

Contoso.InventoryClient

ユーザー向けのDisplay Nameは、次のように設定できます。

在庫管理クライアント

Resourcesタブでは、対応言語をBCP-47形式で指定します。日本語は通常、次のように設定します。

ja-JP

ja_JPのようにアンダースコアを使った形式は避けてください。WinAppはBCP-47言語タグの形式も検証対象にしています。(GitHub)

Dependenciesで対応OSと依存関係を確認する

Dependenciesタブでは、対象となるWindowsのバージョンや、必要なパッケージを設定します。

特に確認したいのは、次の2項目です。

  • MinVersion
  • MaxVersionTested

どちらも、次のような4区切りの形式で指定します。

10.0.17763.0
10.0.26100.0

MaxVersionTestedは、原則としてMinVersion以上の値にします。WinAppの検証では、両方の形式だけでなく、MaxVersionTestedMinVersionより小さくなっていないかも確認されます。(GitHub)

パッケージ依存関係を追加する場合は、依存先のName、Publisher、MinVersionを実際のパッケージ情報と照合してください。入力形式が正しくても、指定した依存パッケージが対象端末に存在しなければ、実行時の問題は防げません。

Capabilitiesは必要なものだけを有効にする

Capabilitiesタブでは、アプリが利用する機能を宣言します。

たとえば、次のような機能があります。

  • Internet Client
  • Microphone
  • デバイス機能
  • Run Full Trust
  • 制限付き機能
  • カスタム機能

XMLを直接編集する場合、機能の種類によってuapdesktoprescapなどの名前空間を宣言し、適切なプレフィックスを付ける必要があります。特に制限付き機能では、xmlns:rescapの宣言漏れや、IgnorableNamespacesへの追加漏れがパッケージ検証エラーの原因になります。(Microsoft Learn)

ビジュアルエディターのフォームやテンプレートを使えば、名前空間を手入力する場面を減らせます。ただし、機能を宣言しただけで利用条件やMicrosoft Storeの審査要件を満たすわけではありません。権限は「将来使うかもしれないもの」をまとめて追加するのではなく、現在のアプリが実際に必要とするものだけを宣言してください。

Applicationsで実行ファイルと拡張機能を設定する

Applicationsタブでは、アプリ本体に関する次の情報を編集します。

  • Application ID
  • Executable
  • Entry Point
  • Trust Level
  • Runtime Behavior
  • Display Name
  • Description
  • Background Color
  • 各種ロゴ
  • スプラッシュスクリーン
  • タイル設定
  • アプリ拡張機能

実行ファイルを指定する場合は、原則としてパッケージ内の相対パスを設定します。

MyApp.exe

サブフォルダーに配置する場合は、次のようになります。

bin\MyApp.exe

開発PC上の絶対パスを設定すると、別のPCやCI環境でパッケージを作成できなくなる可能性があります。

拡張機能はテンプレートから追加する

WinAppでは、代表的なアプリ拡張機能をテンプレートから追加できます。

たとえば、次のような用途です。

拡張機能用途
Protocol Activation独自URLスキームからアプリを起動する
File Type Association特定の拡張子をアプリに関連付ける
App Execution Aliasコマンドラインからアプリを起動する
Startup Taskサインイン時の起動を構成する
Background Tasksバックグラウンド処理を登録する
COM ServerCOMコンポーネントを登録する
App Service他のアプリへサービスを提供する

テンプレートを使うと、必要なXML構造を一から記述せずに済みます。GUID、プロトコル名、ファイル拡張子、実行エイリアスなどの形式も検証されます。(GitHub)

リアルタイム検証で発見できる主なミス

WinApp v0.2のビジュアルエディターは、入力中に必須項目や形式を検証し、問題のあるフィールド付近にエラーを表示します。公式情報では、Publisherの識別名、Version、GUID、BCP-47言語タグ、色、拡張機能の必須フィールドなどが検証対象として示されています。([marketplace.visualstudio.com][2])

よくある入力ミス修正例
Versionが1.0になっている1.0.0.0へ修正する
PublisherがContosoだけになっているCN=ContosoなどのDN形式にする
言語がja_JPになっているja-JPにする
色がFFFFFFになっている#FFFFFFにする
COMのClass IDが不完全正しいGUID形式にする
実行エイリアスに.exeがないmyapp.exeにする
ファイル関連付けにドットがない.txtのように指定する
必須のEntry Pointが空欄実際のエントリーポイントを設定する

リアルタイム検証は、ビルド前に単純な記述ミスを見つけるための機能です。次のような問題まで、すべて保証するものではありません。

  • Publisherと証明書Subjectの実一致
  • 実行ファイルや依存パッケージの中身
  • Microsoft Store側の登録情報との一致
  • 未対応の新しいマニフェストスキーマ
  • 制限付き機能を利用するための承認
  • 実行環境でのファイル配置や権限
  • 署名証明書の期限や信頼状態

エラー表示がなくなっても、最後に実際のMSIXパッケージ作成とインストールテストを行ってください。

Regenerate Assetsでロゴ画像を生成する

Windowsアプリでは、スタートメニュー、タスクバー、タイル、スプラッシュスクリーンなど、用途に応じた複数の画像が必要です。

たとえば、マニフェストではSquare150x150LogoSquare44x44Logoなどが参照されます。Windowsは表示倍率に応じて複数サイズの画像を使い分けるため、手作業で画像を用意すると、ファイル名、パス、縦横比、解像度を間違えやすくなります。(Microsoft Learn)

WinAppでは「Regenerate Assets」を使い、1枚の元画像から必要なサイズを生成できます。

Regenerate Assetsの実行手順

  1. AppxManifest EditorでApplicationsタブを開きます。
  2. 対象アプリのVisual Elementsを表示します。
  3. 「Regenerate Assets」をクリックします。
  4. 元画像を1枚選択します。
  5. アセットの再生成が完了するまで待ちます。
  6. ロゴのプレビューと、生成されたファイルを確認します。
  7. XML内の画像パスが更新されているか確認します。

「Regenerate Assets」を押すと、WinApp CLIのmanifest update-assets処理が呼び出されます。CLIは拡張機能に同梱されているため、通常は別途インストールする必要はありません。(Microsoft for Developers)

元画像は正方形の高解像度PNGが扱いやすい

実務では、透過背景を扱える正方形のPNGを原本として用意すると管理しやすくなります。

ロゴの端に文字や重要な図形を置くと、小さいサイズへ縮小したときに読めなくなったり、表示領域から外れたりします。ロゴ本体の周囲には余白を残してください。

既存のアセットをデザイナーが個別調整している場合、再生成によって生成対象ファイルが更新される可能性があります。実行前にGitへコミットするか、Assetsフォルダーをバックアップしておくと安全です。

コメントや空白を維持したままXMLへ反映される

一般的なXMLフォームエディターでは、ファイル全体を読み込み直して再出力するため、インデント、空白行、属性順、コメントが変わることがあります。その結果、Gitの差分が大量に発生し、実際に変更した箇所が分かりにくくなります。

WinAppのAppxManifest Editorは、変更箇所を基のXMLへ部分的に反映する方式です。既存の空白、コメント、属性順を維持したまま編集できることが公式に案内されています。(Microsoft for Developers)

たとえば、次のコメントを含むXMLを編集しても、関係のないコメントを残したまま変更できます。

<!-- Publisherは署名証明書のSubjectと一致させる -->
<Identity
  Name="Contoso.SampleApp"
  Publisher="CN=Contoso"
  Version="1.0.0.0" />

ただし、要素の追加や削除を行った場合は、関連するXML領域が変わります。保存後は必ずソース管理の差分を確認してください。

XML編集とビジュアルエディターを使い分ける

すべてをビジュアルエディターだけで完結させる必要はありません。

次のように使い分けると効率的です。

作業適した編集方法
PublisherやVersionの修正ビジュアルエディター
対応言語の追加ビジュアルエディター
標準Capabilitiesの追加ビジュアルエディター
ロゴやタイル設定ビジュアルエディター
ProtocolやFile Associationの追加テンプレート付きビジュアルエディター
未対応の新しい名前空間を使うXMLエディター
複雑な独自拡張を記述するXMLエディター
Gitの差分を細かく確認するXMLエディター

通常の項目はビジュアルエディターで入力し、特殊な要件だけXMLで補う方法が現実的です。

実務で推奨する編集からパッケージ作成までの流れ

WinAppのビジュアルエディターを使う場合は、次の順序で進めると手戻りを減らせます。

順序作業
1編集前のAppxManifest.xmlをGitへコミットする
2「Open With…」からAppxManifest Editorを開く
3IdentityのName、Publisher、Versionを確認する
4PropertiesとResourcesを設定する
5DependenciesのOSバージョンと依存関係を確認する
6必要なCapabilitiesだけを追加する
7ApplicationsのExecutableとEntry Pointを確認する
8Regenerate Assetsで画像を生成する
9画面上のエラーと警告を解消する
10XMLエディターへ切り替えてGit差分を確認する
11WinApp: Create MSIX Packageを実行する
12署名、インストール、起動テストを行う

ビジュアルエディターの検証結果だけで完了とせず、パッケージ作成まで実行することが重要です。WinAppではコマンドパレットから「WinApp: Create MSIX Package」を実行でき、証明書生成や署名も同じ拡張機能から操作できます。([marketplace.visualstudio.com][2])

AppxManifest Editorが表示されない場合の確認項目

VS Codeのバージョンを確認する

VS Codeの「Help」から「About」を開き、1.109.0以降になっているか確認します。古い場合はVS Codeを更新してください。

WinApp拡張が有効か確認する

拡張機能ビューでWinAppを開き、次を確認します。

  • インストール済みになっている
  • 無効化されていない
  • v0.2以降になっている
  • ワークスペース単位で無効化されていない

更新後に表示されない場合は、コマンドパレットから「Developer: Reload Window」を実行すると改善することがあります。

ファイル名を確認する

AppxManifest Editorの対象は、基本的に次のファイルです。

AppxManifest.xml
Package.appxmanifest
任意の名前.appxmanifest

通常の.xmlファイルとして別名保存している場合、AppxManifest Editorの候補に表示されない可能性があります。拡張機能の定義でも、AppxManifest.xml*.appxmanifestが対象として登録されています。(GitHub)

ビジュアルエディターが開けない場合の対処法

XML自体が壊れていないか確認する

開始タグと終了タグの不一致、属性値の引用符漏れなどによりXMLを解析できない場合、フォームを正常に表示できません。

その場合は、いったん標準のテキストエディターで開き、次のような基本的なXMLエラーを修正します。

  • 終了タグが不足している
  • 属性値を引用符で囲んでいない
  • &をエスケープしていない
  • 同じ属性を重複している
  • 名前空間プレフィックスを宣言していない

XMLとして解析できる状態に戻した後、再度「Open With…」からAppxManifest Editorを開きます。WinAppの実装でも、XMLを解析できない場合は通常のフォームではなく解析エラー画面を表示する仕組みになっています。(GitHub)

Publisherのエラーが消えない

Publisherには、単なる会社名ではなくX.500識別名を入力します。

誤った例は次のとおりです。

Contoso株式会社

形式上の例は次のとおりです。

CN=Contoso株式会社, O=Contoso株式会社, C=JP

ただし、最終的には署名証明書のSubjectを確認し、その文字列と一致させてください。

Regenerate Assetsが失敗する

次の点を確認します。

  • 選択した元画像をVS Codeから読み取れる
  • 元画像が選択ダイアログで許可される形式になっている
  • マニフェストがあるフォルダーへ書き込める
  • Assetsフォルダーや生成対象ファイルが他のアプリでロックされていない
  • セキュリティ製品がCLIの実行を遮断していない

失敗時には「Asset regeneration failed」とエラー内容が表示されるため、メッセージを確認して原因を切り分けます。(GitHub)

エラーがなくてもパッケージ作成に失敗する場合

リアルタイム検証でエラーが表示されていなくても、MSIX作成時に失敗することはあります。

その場合は、次の順序で確認します。

  1. Publisherと署名証明書のSubjectが完全一致しているか
  2. Executableのファイルが実際に存在するか
  3. CPUアーキテクチャがビルド成果物と一致しているか
  4. 画像パスがパッケージ内の相対パスになっているか
  5. 依存パッケージのName、Publisher、Versionが正しいか
  6. 使用する名前空間が対象OSのスキーマに対応しているか
  7. 制限付きCapabilityの利用条件を満たしているか
  8. パッケージ内に参照先ファイルが含まれているか

ビジュアルエディターは、XMLを安全に編集し、形式上のミスを早期発見するための機能です。実際のファイル構成、証明書、ビルド成果物、配布条件を含めた最終確認は、パッケージ作成とインストールテストで行う必要があります。

WinApp v0.2ではビルド前の検証とXML差分確認を組み合わせる

WinApp v0.2ビジュアルエディターを使うと、AppxManifest.xmlの主要項目をフォームで編集しながら、Publisher、Version、GUID、言語タグ、色、拡張機能などの入力ミスを早い段階で発見できます。

まずWinApp拡張とVS Codeを対応バージョンへ更新し、対象ファイルを右クリックして「Open With…」から「AppxManifest Editor」を開いてください。Identityを最初に確認し、Applicationsで「Regenerate Assets」を実行した後、すべてのエラーを解消します。

最後にXMLへ切り替えてGitの差分を確認し、「WinApp: Create MSIX Package」で実際にパッケージを作成します。この流れにすれば、マニフェストの単純なXMLミスをパッケージ作成時まで持ち越すリスクを減らせます。
[2]: https://marketplace.visualstudio.com/items?itemName=Microsoft-WinAppCLI.winapp “
WinApp – Visual Studio Marketplace

この記事を書いた人

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

コメント

コメントする

目次