Windows アプリ SDKデプロイの概要

Windows アプリ SDKをデプロイする方法は 2 つあります。

  • フレームワークに依存する . アプリは、ターゲット コンピューターに存在する Windows アプリ SDK ランタイムまたはフレームワーク パッケージに依存します。 フレームワークに依存するデプロイは、マシン リソースと保守容易性を効率的に使用するためのWindows アプリ SDKの既定のデプロイ モードです。
  • 自己完結型です。 アプリにはWindows アプリ SDKの依存関係が含まれており、ターゲット コンピューターに別のランタイム をインストールする必要がなくなります。

このトピックでは、 パッケージ アプリ、 外部の場所を持つパッケージ アプリ、パッケージ 化されていないアプリという用語も使用します。 これらの用語の説明については、「 デプロイの概要」を参照してください。

フレームワークに依存するデプロイ 自己完結型のデプロイ
長所 小規模な展開。 あなたのアプリとその依存関係のみが配布されます。 Windows アプリ SDK ランタイムおよびフレームワーク パッケージは、パッケージ化されたフレームワーク依存アプリによって自動的にインストールされます。または、外部の場所でパッケージ化されているか、パッケージ化されていないフレームワークに依存するアプリによって、Windows アプリ SDK ランタイム インストーラーの一部としてインストールされます。

サービス可能。 Windows アプリ SDKのサービス更新プログラムは、Windows アプリ SDK Framework パッケージを介して自動的にインストールされ、アプリの操作は必要ありません。		 Control Windows アプリ SDK version。 アプリでデプロイするWindows アプリ SDKのバージョンを制御します。 Windows アプリ SDKのサービス更新プログラムは、再構築して再配布しない限り、アプリに影響しません。

他のアプリから分離されています。 アプリとユーザーは、アプリ全体をアンインストールしないと、Windows アプリ SDKの依存関係をアンインストールできません。

Xcopy 導入。 Windows アプリ SDKの依存関係はアプリによって実行されるため、追加のインストール要件を必要とせずに、ビルド出力を xcopy で実行するだけでアプリをデプロイできます。
短所 追加のインストール依存関係。 アプリのインストールに複雑さが加わる可能性がある、Windows アプリ SDK ランタイムまたはフレームワーク パッケージのインストールが必要です。

共有依存関係。 共有依存関係がアンインストールされるリスク。 共有コンポーネントをアンインストールするアプリまたはユーザーは、依存関係を共有する他のアプリのユーザー エクスペリエンスに影響を与える可能性があります。

互換性リスク。 Windows アプリ SDKの更新プログラムにサービスを提供すると、破壊的変更が発生するリスク。 サービス更新プログラムは下位互換性を提供する必要がある一方で、回帰が導入される可能性があります。		 大規模なデプロイ (パッケージ化されていないアプリのみ)。 アプリにはWindows アプリ SDKが含まれているため、必要なダウンロード サイズとハード ドライブの領域は、フレームワークに依存するバージョンの場合よりも大きくなります。

パフォーマンス (パッケージ化されていないアプリのみ)。 コード ページは他のアプリと共有されないため、読み込みに時間がかかり、より多くのメモリを使用します。

サービス不可能。 アプリと共に配布されるWindows アプリ SDKバージョンは、アプリの新しいバージョンをリリースすることによってのみ更新できます。 Windows アプリ SDKのサービス更新プログラムをアプリに統合する責任があります。

最初の WinUI 3 プロジェクト を作成すること、そして 既存のプロジェクトで Windows アプリ SDK を使用すること も参照してください。

Note

PublishSingleFile (単一ファイル EXE) は、パッケージ化されていない自己完結型 WinUI 3 アプリ (Windows アプリ SDK 1.5 以降) でサポートされています。 パッケージ アプリとフレームワークに依存するアプリは、 PublishSingleFileをサポートしていません。 必要な MSBuild プロパティについては、 単一ファイル EXE を参照してください。

フレームワークに依存するデプロイの詳細

フレームワーク依存アプリをデプロイ用に構成する前に、アプリがWindows アプリ SDKを使用する場合の依存関係の詳細については、Windows アプリ SDK の Deployment アーキテクチャを確認してください。

パッケージ アプリ

フレームワークに依存するパッケージ 化されたアプリ (Deployment の概要を参照) を選択した場合は、アプリを使用してWindows アプリ SDK ランタイムをデプロイする方法を次に示します。

外部の場所またはパッケージ化されていないアプリでパッケージ化

外部の場所を持つフレームワーク依存のパッケージ 化されたアプリ、またはフレームワークに依存するパッケージ化されていないアプリ (Deployment の概要を参照) を使用することを選択した場合は、アプリで Windows アプリ SDK ランタイムをデプロイする方法を次に示します。

自己完結型デプロイの詳細

自己完結型アプリのWindows アプリ SDK展開ガイドを参照してください。

Note

PublishSingleFile (単一ファイル EXE) では、アプリが パッケージ化されておらず 、 自己完結型である必要があります。 必要な MSBuild プロパティの完全な一覧については、 単一ファイル EXE を参照してください。

Windows アプリ SDKを初期化する

Windows アプリ SDKを初期化する方法は、アプリをパッケージ化するかどうか、およびパッケージ化する方法、およびWindows アプリ SDK ランタイムを基準にしてデプロイする方法によって異なります。 アプリに適用される以下のセクションを使用します。

パッケージ アプリ

アプリのデプロイ方法 初期化方法
フレームワークに依存 を参照してください デプロイの API を呼び出す。
自己完結型 初期化は必要ありません。

パッケージ化されていないアプリと、外部の場所でパッケージ化されたアプリ

アプリのデプロイ方法 初期化方法
フレームワークに依存 外部の場所でパッケージ化されたアプリ、または未パッケージ化のアプリでブートストラップAPIを使用する場合は、、を参照してください。
自己完結型 自動 UndockedRegFreeWinRT サポートのオプトアウト（またはオプトイン）についてはを参照してください。

アーキテクチャに関する考慮事項 (x64、ARM64)

アプリをデプロイするときは、ユーザーが必要とするプロセッサ アーキテクチャごとにバイナリを含める必要があります。 これは、フレームワークに依存するデプロイ モードと自己完結型展開モードの両方に適用されます。

ARM64 のサポート

ARM デバイス (Surface Pro X、Surface Pro 11、Copilot+ PCs を含む) のWindowsは、ARM64 をネイティブに実行します。 x64 エミュレーションは、Windows 11 ARM64 デバイスで使用できますが、ネイティブ ARM64 バイナリはパフォーマンスとバッテリ寿命を向上させ、Copilot+ PCs上のデバイス上の AI ワークロードに最適なエクスペリエンスが必要な場合に推奨されます。

ネイティブ ARM64 のデプロイ

  • MSIX バンドル — .msixbundleアーキテクチャとx64アーキテクチャの両方を含むARM64を作成します。 Visual Studioは、複数のプラットフォーム用にビルドすると自動的に生成されます。 ストアとアプリ インストーラーは、インストール時に適切なアーキテクチャを選択します。

  • 自己完結型発行 — 各アーキテクチャのランタイム識別子 (RID) を指定します。

    dotnet publish -c Release -r win-x64 --self-contained true
dotnet publish -c Release -r win-arm64 --self-contained true

  • C++/WinRT — Visual Studio ソリューションでx64とARM64用の個別の構成を構築します。

  • フレームワークに依存するアプリ - Windows アプリ SDK ランタイム インストーラーを使用する場合は、アーキテクチャ固有の適切なインストーラーを指定してください。 Windows アプリ SDKには、x64 と ARM64 用の個別のインストーラーが付属しています。

Arm64EC — 大規模な C/C++ コードベースの段階的な移行

アプリに大規模なネイティブ (C/C++) コードベースがある場合、ARM64 への完全な再コンパイルは、1 つの手順では実用的でない可能性があります。 Arm64EC (エミュレーション互換) を使用すると、同じプロセスで x64 コードと ARM64 コードを混在できます。 パフォーマンスクリティカルなモジュールはネイティブ ARM64 に再コンパイルしますが、残りの x64 モジュールはすべてエミュレーションで実行されます。これはすべて 1 つのバイナリ内です。

Approach 最適な用途 トレードオフ
ARM64 の完全な再コンパイル 純粋な.NET アプリ、小さな C++ プロジェクト 最高のパフォーマンス。すべての依存関係が ARM64 互換である必要がある
Arm64EC 大規模な C/C++ アプリ、x64 専用プラグインまたはサード パーティ製 DLL を含むアプリ 増分移行。エミュレートされた部分の実行速度がネイティブより遅い
x64 のみ (エミュレート) 再コンパイルできず、ピーク時のパフォーマンスを必要としないアプリ 簡単;ARM64 デバイスでのバッテリ寿命の短縮と待機時間の短縮

詳細については、「 Arm64EC — Arm でのネイティブ パフォーマンスのためのアプリのビルドと移植」を参照してください。

エミュレーション (Prism)

ARM 上のWindows 11では、Prism と呼ばれるエミュレーション レイヤーを使用して、ARM64 ハードウェア上で x64 および x86 アプリを実行します。 Prism は、実行時に x86/x64 命令を ARM64 に変換し、再コンパイルを必要とせずに広範なアプリ互換性を提供します。

  • x64 エミュレーション — Windows 11 ARM64 デバイスでのみ利用できます（ARM 版 Windows 10 は対象外）。
  • x86 エミュレーション— Windows 10デバイスとWindows 11 ARM64 デバイスの両方で使用できます。
  • パフォーマンス - エミュレートされたアプリは、通常、生産性ワークロードに対して許容できるパフォーマンスで実行されますが、グラフィックス集中型またはコンピューティング負荷の高いアプリは、ネイティブ ARM64 または Arm64EC ビルドによって大きなメリットを得られます。

ヒント

x64 のみを対象とする場合、アプリは引き続き Prism エミュレーションを介して ARM64 デバイス上で実行されます (Windows 11のみ)。 ただし、運用アプリにはネイティブ ARM64 ビルドを強くお勧めします。エミュレートされたアプリでは、より多くのバッテリーを使用し、待機時間が長くなります。 Copilot+ PCsでは、ネイティブ ARM64 は、デバイス上の AI ワークロードに最適なパフォーマンスを提供できます。

ストア申請の場合は、アーキテクチャ固有のパッケージまたは両方を含むバンドルをアップロードします。 ストアは、一致するアーキテクチャのみを各デバイスに提供します。

  • Last updated on