【MSIX】単一プロジェクト MSIX パッケージングの仕方

Last updated at 2026-03-07Posted at 2026-03-02

MSIX パッケージングは、Windows App SDK にも UWP にも関係がない独立した概念であるため、理論上どんなアセンブリも MSIX にパッケージングすることができます¹。今まで紆余曲折ありましたが、現在は WAP プロジェクトか Microsoft.Windows.SDK.BuildTools.MSIX NuGet パッケージを通して MSIX パッケージングを行うことができます。

そもそも MSIX とは

MSIX でインストールされたアプリケーションは、Windows が管理する専用のディレクトリに配置され、システムによって一貫した方法で管理されます。そのため、従来の MSI や独自のインストーラーのように、インストール先の管理やアンインストール処理を開発者が個別に実装する必要がほとんどありません。結果として、開発者の実装負担を減らしつつ、ユーザーにとっても安全でクリーンなインストール体験を提供できます。

公式ドキュメントには、以下のようにあります。これは間違ってはいませんが、現状は MakeAppx.exe や SignTool.exe などの CLI ツールを使うか WAP プロジェクトを別途ソリューションに追加して構成する必要があります。Visual Studio における開発では、CLI や追加のプロジェクトを必要とするよりも簡単にパッケージングを行える必要があるはずです。

MSIX パッケージ形式では、Win32、WPF、および Windows フォームアプリの新しい最新のパッケージ化と展開機能を有効にするだけでなく、既存のアプリパッケージの機能やファイルのインストールも保持されます。

もともと WAP プロジェクトという MSIX パッケージング専用のプロジェクトテンプレートを用いて、どのアプリケーションの種類もパッケージングが可能でした。しかし、専用のプロジェクトが必要な理由が見当たりません。そのため、数年前からメインプロジェクトでパッケージングが可能になる「単一プロジェクトパッケージング」が開発されてきました。

WAP プロジェクトによるパッケージング

単一プロジェクトパッケージングによるパッケージング

2024 年後半に UWP がコンパイルツールチェーンを .NET Native（レガシ UWP）から .NET 9+ RyuJIT（モダン UWP）へ移行し、SDK スタイルのプロジェクトの使用によるモダン化がなされたタイミング²で、Windows App SDK での「単一プロジェクトパッケージング」機能は Microsoft.Windows.SDK.BuildTools.MSIX という NuGet パッケージとして分離され、モダン UWP ではデフォルトでこれを参照するようになりました。また、Windows App SDK でもバージョン 1.8 以降、単一プロジェクトパッケージングを行う場合にこの NuGet パッケージを利用するようになりました。

しかしながら、モダン UWP 自体、私の知る限り一人の Microsoft 開発者と一人の Microsoft MVP によって開発されており、ドキュメントの作成までにはリソースが足りなかったようです。この NuGet パッケージについて全く公式ドキュメントが存在せず、Microsoft 開発者による GitHub 上の非公式声明しかなく、筆者自身 GitHub に報告されていないバグも複数発見したため、現在は使うデメリットも大きいです。この NuGet パッケージについて得られる公開情報は Windows App SDK のレポジトリのみです。

将来的には、この NuGet パッケージが様々なプロジェクトの種類で使えることにする予定のようです。

また、現在の状況は分かりませんが、将来的に WAP プロジェクトによるパッケージングを「非推奨」にする予定のようです。

簡単な歴史をまとめるとこのようになるかと思います。

日付	説明
2021/6/26	筆者の知る限り最初期に「Single-project packaging」が紹介される³。
2021/7/9	VisualStudio Marketplace に VS2019/VS2022 向け「Single-projectMSIXPackagingTools」拡張が公開される⁴。
2021/8/13	公式に文書化される⁵。
2021/10/7	Windows App SDK Preview 2 から Windows App SDK の拡張機能に組み込まれる⁶。
2021/12/1	単一アーキテクチャしかパッケージできずバンドルを生成できない問題を公式文書化⁷。
2022/11/3	VS2022 17.1 から Visual Studio の「WinUI アプリケーション開発」ワークロードに組み込まれたことが文書化される⁸。
2024/10/9	.NET 9 UWP の開発に合わせて、パッケージングロジック機能が `Microsoft.Windows.SDK.BuildTools.MSIX` NuGet パッケージに分離独立。
202/9/9	Windows App SDK もバージョン 1.8 から使うようになる。
2026/1/23	5 年越しにバンドルの生成に対応（ver `1.7.251221100`）。

必須プロパティ

これを true に設定して単一プロジェクトパッケージングが有効にします。

<EnableMsixTooling>true</EnableMsixTooling>

シナリオ別

CI 用

通常、CI ではバンドルの生成は行いません。

<AppxBundle>Never</AppxBundle>

msbuild MyProject.csproj -restore /p:Platform=x64 /p:Configuration=Release

サイドローディング用

サイドローディングには msixbundle と appinstaller を生成します。

<!-- ビルド時にパッケージングも行う場合 -->
<GenerateAppxPackageOnBuild>true</GenerateAppxPackageOnBuild>

<UapAppxPackageBuildMode>SideloadOnly</UapAppxPackageBuildMode>
<AppxBundle>Always</AppxBundle>
<AppxBundlePlatforms>x64|arm64</AppxBundlePlatforms>

<!-- appinstaller を生成する -->
<GenerateAppInstallerFile>true</GenerateAppInstallerFile>
<AppInstallerUri>D:\MyAppArtifacts\MyApp.appinstaller</AppInstallerUri>

<!-- appinstaller 等を生成するディレクトリを指定する -->
<AppxPackageDir>D:\MyAppArtifacts\</AppxPackageDir>

GenerateAppxPackageOnBuild が true の場合

msbuild MyProject.csproj -restore /p:Platform=x64 /p:Configuration=Release

その他の場合は GenerateMsixPackage ビルドターゲットによるビルドも用います。

Microsoft Store 用

Microsoft Store へ提出する際に必要となるファイルは msixupload か appxupload です。

<!-- ビルド時にパッケージングも行う場合 -->
<GenerateAppxPackageOnBuild>true</GenerateAppxPackageOnBuild>

<UapAppxPackageBuildMode>StoreOnly</UapAppxPackageBuildMode>

<!-- msixupload を生成するディレクトリを指定する -->
<AppxPackageDir>D:\MyAppArtifacts\</AppxPackageDir>

GenerateAppxPackageOnBuild が true の場合

msbuild MyProject.csproj -restore /p:Platform=x64 /p:Configuration=Release

その他の場合は GenerateMsixPackage ビルドターゲットによるビルドも用います。

機能別

デバッグシンボルをパッケージに追加する

<!-- シンボルを追加する（デフォルト：true） -->
<AppxSymbolPackageEnabled>true</AppxSymbolPackageEnabled>

<!-- プライベートシンボルを追加する（デフォルト：false） -->
<AppxPackageIncludePrivateSymbols>false</AppxPackageIncludePrivateSymbols>

ローカル署名を行う

ローカル署名を行う場面はほとんどありませんが、CI 上でパッケージングとインストールのテストを行う場合に有効です。

<AppxPackageSigningTimestampDigestAlgorithm>sha256</AppxPackageSigningTimestampDigestAlgorithm>
<PackageCertificateKeyFile>SigningCert.pfx</PackageCertificateKeyFile>
<PackageCertificatePassword>パスワード</PackageCertificatePassword>

Azure Trusted Signing で署名する

サイドローディングの署名は Azure Trusted Signing で行うのが推奨されます。

<AzureCodeSigningEnabled>true</AzureCodeSigningEnabled>
<AzureCodeSigningDlibFilePath>...</AzureCodeSigningDlibFilePath>
<AzureCodeSigningEndpoint>...</AzureCodeSigningEndpoint>
<AzureCodeSigningAccountName>...</AzureCodeSigningAccountName>
<AzureCodeSigningCertificateProfileName>...</AzureCodeSigningCertificateProfileName>

Azure Key Vault を使用する

<AzureKeyVaultUrl>...</AzureKeyVaultUrl>
<AzureKeyVaultCertificateId>...</AzureKeyVaultCertificateId>

リソース修飾子をカスタマイズする

通常、言語リソースやスケール対応画像リソースは、MSIX のインストール時に、インストール先のコンピュータ構成に応じて必要な項目のみが選択されてインストールされます。
たとえば英語環境では英語リソースのみがインストールされ、Windows の表示言語を日本語に変更した場合は、日本語リソースのみが自動的にインストールされます。

しかし、アプリケーション側で言語を切り替えられるほうが、より柔軟で効率的な UX を提供できるケースも少なくありません。これは、自動リソース修飾子をカスタマイズすることで実現できます。

AppxBundleAutoResourcePackageQualifiers には、特定のスケールや言語リソース、DirectX 機能レベルなど、MSIX が自動的に判定して必要な項目のみをインストールする対象を指定します。既定値は Language|Scale|DXFeatureLevel です。

インストールさせる言語リソースをカスタマイズしたい場合は、Language を除外します。

<AppxBundleAutoResourcePackageQualifiers>Scale|DXFeatureLevel</AppxBundleAutoResourcePackageQualifiers>

さらに、インストール対象とする言語を AppxDefaultResourceQualifiers に明示します。

<AppxDefaultResourceQualifiers>Language=en;es;fr</AppxDefaultResourceQualifiers>

公式ドキュメントにも同様の説明がありますが、これはレガシー UWP を前提とした内容です。現在主流の SDK スタイルプロジェクトでは、priconfig.packaging.xml を使用する必要はありません。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up