次の方法で共有

Windows アプリ: パッケージ化、デプロイ、プロセス

  • [アーティクル]

Note

一部の情報はリリース前の製品に関する事項であり、正式版がリリースされるまでに大幅に変更される可能性があります。 Microsoft はここに示されている情報について、明示か黙示かを問わず、一切保証しません。

このトピックでは、次に関するオプションについて説明します。

  • アプリをパッケージ化するかどうか。
  • アプリのデプロイ/配布方法と、アプリのインストール方法。
  • アプリの実行時プロセス — どのように分離されるかと、それに使用できる API。

これらの決定は、新規と既存の両方のアプリに対して行うことができます。 ただし、まだ新しいアプリの計画段階にある場合は、上記の考慮事項を検討する前に、アプリに使用する開発プラットフォームとユーザー インターフェイス (UI) フレームワークをまず決定してください。 その決定については、「Windows 開発オプションの概要」を参照してください。

パッケージまたは非パッケージ

アプリをパッケージにするか、非パッケージにするかの決定は、まず "パッケージ ID" と呼ばれる概念によって決まります。これについては、このセクションで説明します。 それが必要ない場合は、自分およびユーザーの目的のインストーラー エクスペリエンスに応じて決定することになります。 それらの詳細を詳しく見てみましょう。

バックグラウンド タスク、通知、ライブ タイル、カスタム コンテキスト メニュー拡張機能、共有ターゲットなどの、Windows 拡張機能の多くは、実行時にアプリにパッケージ ID がある場合にのみ、そのアプリで使用できます。 これは、オペレーティング システム (OS) で対応する API の呼び出し元を識別できる必要があるためです。 「パッケージ ID が必要な機能」を参照してください。

  • これらの機能のいずれかを使用する必要がある場合は、アプリにパッケージ ID が必要です。 そのため、パッケージ アプリである "必要があります" (パッケージ アプリが、パッケージ ID を持つ唯一の種類です)。 パッケージ アプリは、MSIX テクノロジを使用してパッケージ化されます (「MSIX とは」を参照)。
    • 新しいアプリの場合、パッケージ化プロセスは単純です (このセクションの最後に、その方法に関する情報があります)。
    • 一部の既存のアプリについては、新しいアプリと同じパッケージ化プロセスに従うことができます。 ただし、既存のアプリの一部はすべてのコンテンツを MSIX パッケージに格納する準備がまだできていないため、アプリを "外部の場所でパッケージ化" するオプションがあります。 それを使用すると、アプリはパッケージ ID を持つことができ、これにより必要な機能を使用できます。 詳細については、「外部の場所でパッケージ化してパッケージ ID を付与する」を参照してください。
  • これらの機能を使用する必要が "ない" 場合でも、パッケージ アプリを作成することをお勧めします。 ユーザーがアプリのインストール、アンインストール、更新を行う方法が最も簡単になります。 詳細については、このトピックの「デプロイ/配布/インストール」を参照してください。
  • ただし、非パッケージ アプリの作成は 1 つの選択肢です。

重要な点は、パッケージ アプリはパッケージ ID を持つ唯一の種類であること (およびインストール エクスペリエンスが最も優れていること) です。 非パッケージ アプリにはパッケージ ID がありません。そのため、上で言及した API/機能を使用できません。

パッケージと非パッケージの詳細については、「デプロイの概要」、特にそのトピックの「アプリをパッケージ化することの長所と短所」セクションを参照してください。 そのトピックでは、"外部の場所でパッケージ化" オプションにも触れています。

アプリをパッケージまたは非パッケージとして構成する方法については、以降を参照してください。

このトピックの「Windows パッケージ マネージャーと WinGet クライアント」セクションも参照してください。

デプロイ/配布/インストール

  • パッケージ アプリは、MSIX テクノロジを使用してパッケージ化されます。
    • パッケージ アプリは、"インストール" も MSIX を使用して行われます。 ただし、"外部の場所でパッケージ化" を選択した場合は、それを "独自のインストーラーの持ち込み" モデルと考えることができます。 そのため、そのオプションで実行するインストーラーの作業がいくつか "発生します"。 詳細については、「外部の場所でパッケージ化してパッケージ ID を付与する」を参照してください。
  • 非パッケージ アプリには、MSIX がまったく含まれません。

では、アプリがパッケージ化されているかどうかは、なぜ重要なのでしょうか。

  • MSIX を使用すると、ユーザーがアプリのインストール、アンインストール、更新を行う方法が簡単になります。 アンインストールとは削除です。アプリがアンインストールされると、システムはインストール前と同じ状態に復元され、成果物は残りません。
  • この種のアプリでは、増分更新と自動更新もサポートされています。
  • Microsoft Store は、この種のアプリ用に最適化されています (それらは Microsoft Store 内でも外でも使用できます)。
  • これは、MSIX アプリ アタッチ (Azure Virtual Desktop 仮想マシンの場合) 経由で使用するための簡単なパスです。 詳細については、「MSIX アプリのアタッチとは」を参照してください。
  • 署名されたパッケージは、強力な改ざん防止という利点があります。 この利点は、Program Files 下にインストールされている非パッケージ アプリよりさらに優れています。

このトピックの「Windows パッケージ マネージャーと WinGet クライアント」セクションも参照してください。

AppContainer または Medium IL

AppContainer でアプリを実行するかどうかは、セキュリティの問題です。 AppContainer アプリのプロセスとその子プロセスは、軽量のアプリ コンテナー内で実行されます。ここでは、それらに対して明示的に許可されたリソースにのみアクセスできます。 また、ファイル システムとレジストリの仮想化を使用して分離されています。 その結果、AppContainer に実装されたアプリがハッキングされて、限定的に割り当てられているリソース以外に対する悪意のあるアクションを許可してしまうことはありません。

パッケージまたは非パッケージ アプリは、AppContainer で実行するように構成できます。 ただし、パッケージ アプリの方がプロセスがより単純です。 アプリが AppContainer アプリでない場合は、Medium IL アプリです。

詳細については、「レガシ アプリの AppContainer」と「MSIX AppContainer アプリ」を参照してください。

AppContainer または Medium IL で実行するようにアプリを構成する方法については、以降を参照してください。

  • WinUI 3 アプリ (Windows App SDK): 「AppContainer 用の WinUI 3 プロジェクトを構成する」の uap10:TrustLevel アプリ パッケージ マニフェスト属性を参照してください。
  • デスクトップ アプリ: 「MSIX AppContainer アプリ」の TrustLevel Visual Studio プロジェクト プロパティ (アプリの種類に適したセクション内) を参照してください。
  • ユニバーサル Windows プラットフォーム (UWP) アプリ: UWP アプリは、AppContainer で実行するように既に構成されていて、その構成を変更することはできません。

非パッケージ アプリにはアプリ パッケージ マニフェストがないことを思い出してください。 そのため、非パッケージ アプリの場合は、アプリ パッケージ マニフェストではなく、プロジェクト ファイルで AppContainer または Medium IL の決定を宣言します。

Win32 アプリの分離

重要

このトピックで説明する機能は、Windows Insider Preview のプレリリース バージョンで使用できます。

Win32 アプリの分離は、アプリが侵害された場合に損害を封じ込め、ユーザーのプライバシーの選択を保護するのに役立つ、近日公開される Windows のセキュリティ機能です。 この機能は、AppContainers と、リソースを仮想化し、他のリソースへの仲介型アクセスを提供するコンポーネントという基盤上に構築されています。 アプリの分離に役立つドキュメントとツールについては、「Welcome to the Win32 app isolation repo」を参照してください。

アプリの機能

アプリの機能 (internetClient、場所、マイク、Bluetooth など) は、主に "AppContainer で実行されるパッケージ アプリ" に関連します。 つまり、これには "すべての" ユニバーサル Windows プラットフォーム (UWP) アプリと、"一部の" デスクトップ アプリが含まれます。

ただし、Medium IL アプリ (つまり、AppContainer アプリ "以外") でも機能を宣言する必要があるシナリオがあります。 1 つの例として runFullTrust 制限付き機能があります。

アプリの機能、該当するアプリの種類、およびそれらの構成方法の詳細については、「アプリ機能の宣言」を参照してください。 機能はアプリ パッケージ マニフェストで構成します。そのため、これらはパッケージ アプリにのみ適用されます。

アプリの種類

"デスクトップ アプリ" ファミリにはいくつかの種類のアプリがありますが、デスクトップ アプリと ユニバーサル Windows プラットフォーム (UWP) アプリが 2 つの主要な種類のアプリです。 ユーザー インターフェイス (UI) フレームワーク (WinForms、WPF、Win32、Direct 2D/3D、UWP、または WinUI 3) の選択は、このトピックで説明する構成からある程度独立した 1 つのオプションです。

しかし、パッケージ化、デプロイ、プロセスの観点から、これらのアプリの種類が互いにどのように異なるかを見てみましょう。

まず、すべての UWP アプリはパッケージ化され、AppContainer で実行されます。 ただし、デスクトップ アプリの場合は、柔軟性が高くなります。 デスクトップ アプリをパッケージ化するかどうかは選択できます。 また、その決定とは別に、デスクトップ アプリを AppContainer と Medium IL アプリのどちらとして構成するかを選択できます。

パッケージに含まれる 非パッケージ
AppContainer デスクトップ アプリ
UWP アプリ		 デスクトップ アプリ
Medium IL デスクトップ アプリ デスクトップ アプリ

パッケージ アプリの場合、必要なアプリの種類を構成するには、アプリ パッケージ マニフェストで uap10:RuntimeBehavior 属性を使用します (「アプリケーション (Windows 10)」を参照)。

  • デスクトップ アプリは Windows の .exe であり、通常は main または WinMain エントリ ポイント関数を使用します。 アプリをデスクトップ アプリとして構成するには、uap10:RuntimeBehavior を "packagedClassicApp" または "win32App" に設定します。
    • 値 "packagedClassicApp" は、WinUI 3 アプリ (Windows アプリ SDK) またはデスクトップ ブリッジ アプリ (Centennial) を示します。 違いは、Centennial アプリは AppContainer で実行される点です。
    • "win32App" は、その他の任意の種類の Win32 アプリ (外部の場所でパッケージ化されたアプリを含む) を示します。
  • 最後に、uap10:RuntimeBehavior を "windowsApp" に設定すると、UWP アプリが提供されます。

開発できるアプリの種類に関するすべてのオプションについては、「Windows アプリの開発: オプションと機能」を参照してください。

Windows アプリ SDK — フレームワーク依存または自己完結型

Windows アプリ SDK を利用するアプリを開発または保守する場合は、さらに決定する事項があります。 アプリが依存する Windows アプリ SDK をデプロイするには、次の 2 つの方法があるためです。

  • フレームワーク依存 (既定値)。 アプリは、ターゲット マシンに Windows アプリ SDK ランタイムまたはフレームワーク パッケージ、あるいはその両方が存在することを必要とします。
  • 自己完結型。 アプリ自身に、その Windows アプリ SDK の依存関係が含まれています。

「Windows App SDK 展開の概要」を参照してください。

Windows パッケージ マネージャーと WinGet クライアント

パッケージ マネージャーは、ワークフローを自動化することで、ユーザーがソフトウェアのインストール、アップグレード、構成を行うのに役立ちます。 パッケージ マネージャーは任意のソフトウェアのインストールに役立ちますが、主に開発者ツールをインストールするために使用される傾向があります。 したがって、開発者ツールを構築している場合は、このオプションに興味があるかもしれません。 ただし、そのしくみを次に示します。

  • お客様は、ソフトウェア開発者として、製品の正常なインストールに必要なすべての要素をパッケージ マネージャーに (宣言命令の形式で) 定義します。
  • ユーザーがソフトウェアをインストールすると、パッケージ マネージャーは宣言型の指示に従って、インストールと構成のワークフローを自動化します。

その結果、ユーザーの環境の準備に費やされる時間が短縮され、インストールされているコンポーネント間の互換性が向上します。 また、Windows パッケージ マネージャーを使用して、パッケージ化されたアプリやパッケージ化されていないアプリを .msix、.msi、.exe などの形式で配布できます。

詳細については、「Windows パッケージ マネージャー」を参照してください。