このトピックでは、Windows アプリ パッケージを作成できるデスクトップ アプリの種類と、注意が必要なオペレーティング システム (OS) の動作とその他の詳細について説明します。 次の項目の詳細について説明します (ご覧のとおり、特定の動作はアプリの種類によって異なります)。
デスクトップ アプリの種類
作成してパッケージ化できるデスクトップ アプリには 2 種類あります。 アプリケーション要素の uap10:RuntimeBehavior 属性を使用して、アプリ パッケージ マニフェストで アプリ の型を宣言します。
- 1 つの種類には、WinUI 3 アプリ ( Windows アプリ SDK を使用) とデスクトップ ブリッジ アプリ (Centennial) の両方が含まれます。
uap10:RuntimeBehavior="packagedClassicApp"で宣言されます。 - その他の種類は、 外部の場所でパッケージ化されたアプリなど、他の種類の Win32 アプリを表します。
uap10:RuntimeBehavior="win32App"で宣言されます。
ユニバーサル Windows プラットフォーム (UWP) アプリ (uap10:RuntimeBehavior="windowsApp") もパッケージ化されていますが、このトピックではパッケージ化されていません。
次に、(同じ Application 要素の) uap10:TrustLevel 属性によって、パッケージ化されたアプリのプロセスがアプリ コンテナー内で実行されるかどうかが決まります。
-
完全信頼アプリ。
uap10:TrustLevel="mediumIL"で宣言されます。 -
appContainer アプリ。
uap10:TrustLevel="appContainer"で宣言されます。 軽量のアプリ コンテナーで実行されます (したがって、ファイル システムとレジストリの仮想化を使用して分離されます)。 詳細については、 MSIX appContainer アプリに関するページを参照してください。
重要
詳細、依存関係、および機能の要件については、 アプリケーションのこれら 2 つの属性のドキュメントを参照してください。 また、uap10 は Windows 10 バージョン 2004 (10.0; ビルド 19041) で導入されました。
パッケージ化の目的とアプリ コンテナー
アプリをパッケージ化する目的は、実行時に アプリにパッケージ ID を 付与することです。 特定の Windows 機能にはパッケージ ID が必要です ( パッケージ ID を必要とする機能を参照)。 上記で説明 した アプリの種類のすべての組み合わせをパッケージ化できます (これにより 、パッケージ ID の利点があります)。
ただし、 appContainer アプリの主な目的は、他のアプリとの互換性を維持しながら、アプリの状態を可能な限りシステム状態から分離することです。 Windows では、実行時にファイル システムとレジストリに加える特定の変更を検出してリダイレクトすることで実現します ( 仮想化と呼ばれます)。 セクションが仮想化されたアプリにのみ適用される場合は、このセクションを呼び出します。
取り付け
アプリ パッケージは、システム全体ではなく、ユーザーごとにインストールされます。 新しいマシン上の新しいパッケージの既定の場所は、 C:\Program Files\WindowsApps\<package_full_name>の下にあり、実行可能ファイルはapp_name.exeという名前 です 。 ただし、パッケージは他の場所にインストールできます。たとえば、Visual Studio の Start コマンドでは、プロジェクトの $(OutDir)が使用されます。
展開後、パッケージ ファイルは読み取り専用としてマークされ、オペレーティング システム (OS) によって大幅にロックダウンされます。 Windows では、これらのファイルが改ざんされた場合にアプリを起動できません。
C:\Program Files\WindowsAppsの場所は PackageVolume と呼ばれます。 その場所は、Windows が付属している既定の PackageVolume です。ただし、任意のドライブと任意のパスに PackageVolume を作成できます。 さらに、すべてのパッケージが PackageVolume にインストールされているわけではありません (上記の Visual Studio の例を参照してください)。
ファイル システム
OS では、フォルダーの場所に応じて、パッケージ化されたデスクトップ アプリのさまざまなレベルのファイル システム操作がサポートされます。
デバイス用に最適化
ファイルの重複を回避するために (ディスクストレージ領域を最適化し、ファイルをダウンロードするときに必要な帯域幅を減らすために)、OS は単一のストレージとファイルのハードリンクを利用します。 ユーザーが MSIX パッケージをダウンロードすると、 AppxManifest.xml を使用して、パッケージに含まれるデータが以前のパッケージインストールからディスクに既に存在するかどうかを判断します。 同じファイルが複数の MSIX パッケージに存在する場合、OS は共有ファイルを 1 回だけディスクに格納し、両方のパッケージから共有ファイルへのハード リンクを作成します。 ファイルは 64 Kb ブロックでダウンロードされるため、ダウンロードされるファイルの割合がディスクに存在する場合でも、異なる増分のみがダウンロードされます。 これにより、ダウンロードに使用される帯域幅が減少します。
Windows 10 バージョン 1903 以降での AppData 操作
このセクションは、仮想化されたアプリにのみ適用されます。
ユーザーの AppData フォルダー ( C:\Users\<user_name>\AppData など) に新しく作成されたすべてのファイルとフォルダーは、ユーザーごとのプライベートなアプリごとの場所に書き込まれますが、実行時にマージされて実際の AppData の場所に表示されます。 これにより、アプリ自体でのみ使用される成果物の状態をある程度分離できます。これにより、アプリのアンインストール時にシステムがこれらのファイルをクリーンアップできるようになります。
ユーザーの AppData フォルダーの下にある既存のファイルに対する変更は、アプリと OS 間の互換性と対話性を高めるために許可されます。 これにより、OS がアプリによって行われたすべてのファイルまたはディレクトリの変更を認識するため、システムの "ロット" が減少します。 状態の分離により、パッケージ化されたデスクトップアプリは、同じアプリの非パッケージ化バージョンで停止した地点から再開することができます。 OS は、ユーザーの AppData フォルダーの仮想ファイル システム (VFS) フォルダーをサポートしていません。
Windows 10 バージョン 1903 より前の OS での AppData 操作
このセクションは、仮想化されたアプリにのみ適用されます。
ユーザーの AppData フォルダー ( C:\Users\<user_name>\AppData など) へのすべての書き込み (作成、削除、更新など) は、ユーザーごとのプライベートなアプリごとの場所への書き込み時にコピーされます。 これは、パッケージ化されたアプリが実際にプライベート コピーを変更するときに、実際の AppData を編集しているという錯覚を生み出します。 そのように書き込みをリダイレクトすることで、システムはアプリによって行われたすべてのファイル変更を追跡できます。 これにより、アプリのアンインストール時にシステムがこれらのファイルをクリーンアップできるため、システムの "rot" が減少し、ユーザーのアプリの削除エクスペリエンスが向上します。
作業ディレクトリとアプリケーション ファイル
このセクションは、仮想化されたアプリにのみ適用されます。
AppDataのリダイレクトに加えて、Windows の既知のフォルダー (System32、Program Files (x86)など) は、アプリ パッケージ内の対応するディレクトリと動的にマージされます。 各パッケージには、ルートに VFS という名前のフォルダーが含まれています。
VFS ディレクトリ内のディレクトリまたはファイルの読み取りはすべて、実行時に対応するネイティブ ディレクトリとマージされます。 たとえば、アプリにはアプリ パッケージの一部として C:\Program Files\WindowsApps\<package_full_name>\VFS\SystemX86\vc10.dll が含まれている可能性がありますが、ファイルは C:\Windows\System32\vc10.dllにインストールされているように見えます。 これは、ファイルがパッケージ以外の場所に存在することを期待するデスクトップ アプリとの互換性を維持します。
アプリ パッケージ内のファイル/フォルダーへの書き込みは許可されません。 パッケージの一部ではないファイルやフォルダーへの書き込みは、OS によって無視され、ユーザーがアクセス許可を持っている限り許可されます。
ファイル システムの一般的な操作
この短い参照表は、一般的なファイル システム操作と、OS での処理方法を示しています。
| オペレーション | 結果 | 例 |
|---|---|---|
| 既知の Windows ファイルまたはフォルダーの読み取りまたは列挙 | 対応するローカル システムとの C:\Program Files\<package_full_name>\VFS\<well_known_folder> の動的マージ。 |
読み取り C:\Windows\System32 は、 C:\Windows\System32 の内容と C:\Program Files\WindowsApps\<package_full_name>\VFS\SystemX86の内容を返します。 |
この欄の下に書き込んでください AppData |
Windows 10 バージョン 1903 以降: 次のディレクトリの下に作成された新しいファイルとフォルダーは、ユーザーごと、パッケージごとのプライベートな場所にリダイレクトされます。
AppData の場所からファイルを開こうとします。 ファイルが実際の AppData の場所から開かれている場合、そのファイルの仮想化は行われません。 ユーザーがアクセス許可を持っている場合、AppData のファイルの削除が許可されます。Windows 10 より前のバージョン 1903: ユーザーごと、アプリごとの場所にコピー オン ライトします。 |
AppData は通常 C:\Users\<user_name>\AppData。 |
| パッケージ内に書き込む | 許可されていません。 パッケージは読み取り専用です。 |
C:\Program Files\WindowsApps\<package_full_name>での書き込みはできません。 |
| パッケージの外部に書き込む | ユーザーがアクセス許可を持っている場合に許可されます。 | パッケージにC:\Windows\System32\foo.dllが含まれていない場合、C:\Program Files\WindowsApps\<package_full_name>\VFS\SystemX86\foo.dllへの書き込みが許可され、ユーザーにアクセス許可が与えられます。 |
パッケージ化された VFS の場所
このセクションは、仮想化されたアプリにのみ適用されます。
次の表は、パッケージの一部として出荷されるファイルが、アプリのシステム上でオーバーレイされる場所を示しています。 実際に C:\Program Files\WindowsApps\<package_full_name>\VFS内のリダイレクトされた場所にある場合、アプリはこれらのファイルが一覧表示されたシステムの場所にあると認識されます。
FOLDERID の場所は KNOWNFOLDERID 定数から取得されます。
| システムの場所 | リダイレクトされた場所 ([<package_root>]\VFS の下) | アーキテクチャで有効 |
|---|---|---|
| FOLDERID_SystemX86 | SystemX86 |
x86、amd64 |
| FOLDERID_System | SystemX64 |
amd64 |
| FOLDERID_ProgramFilesX86 | ProgramFilesX86 |
x86、amd6 |
| FOLDERID_ProgramFilesX64 | ProgramFilesX64 |
amd64 |
| FOLDERID_ProgramFilesCommonX86 | ProgramFilesCommonX86 |
x86、amd64 |
| FOLDERID_ProgramFilesCommonX64 | ProgramFilesCommonX64 |
amd64 |
| FOLDERID_Windows | Windows |
x86、amd64 |
| FOLDERID_ProgramData（プログラムデータフォルダーID） | 共通の AppData |
x86、amd64 |
| FOLDERID_System\catroot | AppVSystem32Catroot |
x86、amd64 |
| FOLDERID_System\catroot2 | AppVSystem32Catroot2 |
x86、amd64 |
| FOLDERID_System\drivers\etc | AppVSystem32DriversEtc |
x86、amd64 |
| FOLDERID_System\driverstore | AppVSystem32Driverstore |
x86、amd64 |
| FOLDERID_System\logfiles | AppVSystem32Logfiles |
x86、amd64 |
| FOLDERID_System\スプール | AppVSystem32Spool |
x86、amd64 |
レジストリ
このセクション (およびそのサブセクション) は、仮想化されたアプリにのみ適用されます。
アプリ パッケージには、実際のレジストリ内の registry.dat と同等の論理 (仮想) として機能する ファイルが含まれています。 実行時に、仮想レジストリは、そのハイブの内容をネイティブ システム ハイブにマージして、両方の単一のビューを提供します。 たとえば、 registry.dat に 1 つのキー Foo が含まれている場合、実行時の HKLM\Software の読み取りには、(すべてのネイティブ システム キーに加えて) Foo も含まれているように見えます。
MSIX パッケージには HKLM キーと HKCU キーが含まれていますが、処理方法は異なります。 HKLM\Software の下のキーのみがパッケージの一部です。HKCU またはレジストリの他の部分の下のキーは使用されません。 パッケージ内のキーまたは値への書き込みは許可されません。 ユーザーがアクセス許可を持っている限り、パッケージの一部ではないキーまたは値への書き込みが許可されます。
HKCU に基づくすべての書き込みは、書き込み時に、ユーザーごとのプライベートなアプリごとの場所にコピーされます。 従来、アンインストーラーは、ログアウトしたユーザーのレジストリ データがマウント解除され、使用できないため、 HKEY_CURRENT_USER をクリーンアップできません。
すべての書き込みはパッケージのアップグレード中に保持され、アプリが完全に削除された場合にのみ削除されます。
一般的なレジストリ操作
このセクションのほとんどは、仮想化されたアプリにのみ適用されます。
この短い参照表は、一般的なレジストリ操作と、OS がそれらを処理する方法を示しています。
| オペレーション | 結果 | 例 |
|---|---|---|
| HKLM\Software を列挙または読み取り | パッケージ ハイブと、対応するローカル システムの動的マージ。 |
registry.datに 1 つのキー Foo が含まれている場合、実行時に HKLM\Software の読み取りで HKLM\Software と HKLM\Software\Foo の両方の内容が表示されます。 |
| HKCU に書き込みます | ユーザーごと、アプリごとのプライベートな場所にコピー オン ライトされます。 | ファイルの AppData と同じです。 |
| パッケージ内に書き込みます。 | 許可されていません。 パッケージは読み取り専用です。 | パッケージ ハイブに対応するキー/値が存在する場合、 HKLM\Software での書き込みは許可されません。 |
| パッケージ外に書き込みます | OS によって無視されます。 ユーザーがアクセス許可を持っている場合に許可されます。 | HKLM\Software での書き込みは、対応するキー/値がパッケージ ハイブに存在せず、ユーザーが適切なアクセス許可を持っている限り許可されます。 |
アンインストール
このセクションは、仮想化されたアプリにのみ適用されます。
ユーザーがパッケージをアンインストールすると、 C:\Program Files\WindowsApps\<package_full_name> の下にあるすべてのファイルとフォルダー、およびパッケージ化プロセス中にキャプチャされた AppData またはレジストリへのリダイレクトされた書き込みが削除されます。