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バージョン、パッケージ依存関係 |
| Resources | ja-JPなどのBCP-47言語タグ |
| Capabilities | インターネット、マイク、制限付き機能、デバイス機能 |
| Applications | 実行ファイル、エントリーポイント、信頼レベル、ロゴ、タイル、拡張機能 |
Applicationsでは、プロトコルアクティベーション、COM Server、バックグラウンドタスク、ファイルの関連付け、App Service、実行エイリアス、スタートアップタスクなども追加できます。依存関係やリソースは並べ替えられ、XMLに出力される順序を調整できます。([marketplace.visualstudio.com][2])
WinApp v0.2の利用条件
利用前に、OSとVS Codeのバージョンを確認してください。
| 項目 | 必要条件 |
|---|---|
| OS | Windows 10以降 |
| VS Code | 1.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からインストールする手順は次のとおりです。
- VS Codeを起動します。
Ctrl+Shift+Xを押して拡張機能ビューを開きます。- 検索欄に「WinApp」と入力します。
- Microsoft提供のWinApp拡張を選択します。
- 「Install」をクリックします。
- インストール後、必要に応じてVS Codeを再読み込みします。
コマンドラインからインストールする場合は、次のコマンドを使用します。
code --install-extension Microsoft-WinAppCLI.winapp
拡張機能の詳細画面に古いバージョンが表示されている場合は、更新を実行してv0.2以降にしてください。公式のインストール手順でも、拡張機能ビューから「WinApp」を検索する方法と上記コマンドが案内されています。(Microsoft for Developers)
AppxManifest Editorを開く手順
WinAppのビジュアルエディターは、通常のXMLエディターとは別のエディターとして登録されます。
- VS CodeでWindowsアプリのプロジェクトフォルダーを開きます。
- エクスプローラーから
AppxManifest.xmlまたは.appxmanifestファイルを探します。 - 対象ファイルを右クリックします。
- 「Open With…」を選択します。
- 一覧から「AppxManifest Editor」を選択します。
ファイルを通常どおりダブルクリックしたときにXMLが表示されても、拡張機能の故障とは限りません。右クリックして「Open With…」を選び直してください。
ビジュアルエディターからXMLを直接確認したくなった場合も、同じ「Open With…」から標準のテキストエディターへ切り替えられます。WinAppではビジュアルエディターが任意選択のエディターとして登録されており、元のXMLへいつでも戻れる設計です。(GitHub)
Identityタブでパッケージ識別情報を設定する
最初に確認したいのがIdentityタブです。ここに誤りがあると、パッケージ作成、署名、更新、インストールの各工程で問題が発生します。
| 項目 | 入力例 | 確認ポイント |
|---|---|---|
| Name | Contoso.SampleApp | 予約済みのパッケージ名や既存パッケージと一致させる |
| Publisher | CN=Contoso, O=Contoso Ltd | X.500識別名の形式で入力する |
| Version | 1.2.0.0 | Major.Minor.Build.Revisionの4区切りにする |
| Processor Architecture | x64 | ビルド対象のアーキテクチャと合わせる |
| 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のNameやPublisherとは役割が異なります。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の検証では、両方の形式だけでなく、MaxVersionTestedがMinVersionより小さくなっていないかも確認されます。(GitHub)
パッケージ依存関係を追加する場合は、依存先のName、Publisher、MinVersionを実際のパッケージ情報と照合してください。入力形式が正しくても、指定した依存パッケージが対象端末に存在しなければ、実行時の問題は防げません。
Capabilitiesは必要なものだけを有効にする
Capabilitiesタブでは、アプリが利用する機能を宣言します。
たとえば、次のような機能があります。
- Internet Client
- Microphone
- デバイス機能
- Run Full Trust
- 制限付き機能
- カスタム機能
XMLを直接編集する場合、機能の種類によってuap、desktop、rescapなどの名前空間を宣言し、適切なプレフィックスを付ける必要があります。特に制限付き機能では、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 Server | COMコンポーネントを登録する |
| 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アプリでは、スタートメニュー、タスクバー、タイル、スプラッシュスクリーンなど、用途に応じた複数の画像が必要です。
たとえば、マニフェストではSquare150x150LogoやSquare44x44Logoなどが参照されます。Windowsは表示倍率に応じて複数サイズの画像を使い分けるため、手作業で画像を用意すると、ファイル名、パス、縦横比、解像度を間違えやすくなります。(Microsoft Learn)
WinAppでは「Regenerate Assets」を使い、1枚の元画像から必要なサイズを生成できます。
Regenerate Assetsの実行手順
- AppxManifest EditorでApplicationsタブを開きます。
- 対象アプリのVisual Elementsを表示します。
- 「Regenerate Assets」をクリックします。
- 元画像を1枚選択します。
- アセットの再生成が完了するまで待ちます。
- ロゴのプレビューと、生成されたファイルを確認します。
- 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を開く |
| 3 | IdentityのName、Publisher、Versionを確認する |
| 4 | PropertiesとResourcesを設定する |
| 5 | DependenciesのOSバージョンと依存関係を確認する |
| 6 | 必要なCapabilitiesだけを追加する |
| 7 | ApplicationsのExecutableとEntry Pointを確認する |
| 8 | Regenerate Assetsで画像を生成する |
| 9 | 画面上のエラーと警告を解消する |
| 10 | XMLエディターへ切り替えてGit差分を確認する |
| 11 | WinApp: 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作成時に失敗することはあります。
その場合は、次の順序で確認します。
Publisherと署名証明書のSubjectが完全一致しているかExecutableのファイルが実際に存在するか- CPUアーキテクチャがビルド成果物と一致しているか
- 画像パスがパッケージ内の相対パスになっているか
- 依存パッケージのName、Publisher、Versionが正しいか
- 使用する名前空間が対象OSのスキーマに対応しているか
- 制限付きCapabilityの利用条件を満たしているか
- パッケージ内に参照先ファイルが含まれているか
ビジュアルエディターは、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
“

コメント