Поделиться через

Общие сведения о том, как упакованые классические приложения работают в Windows

В этом разделе описываются типы классических приложений, для которых можно создать пакет приложений Windows, а также некоторые поведения операционной системы (ОС) и другие особенности, которые важно учитывать. Мы рассмотрим следующие элементы (как мы увидим, конкретное поведение зависит от типа приложения):

  • Расположение установки и рабочий каталог вашего приложения (который может отличаться от того, что предполагалось ранее).
  • Поведение файловой системы и реестра операционной системы.
  • Удаление.

Типы настольных приложений

Существует два типа настольных приложений, которые можно создать и упаковать. Тип приложения объявляется в манифесте пакета приложения с помощью атрибута uap10:RuntimeBehavior элемента Application :

  • Один тип включает оба приложения WinUI 3 (которые используют Windows App SDK) и приложения Desktop Bridge (Centennial). Объявлен с uap10:RuntimeBehavior="packagedClassicApp".
  • Другой тип охватывает остальные виды приложений Win32, включая приложения, упакованные для внешнего размещения. Объявлен с uap10:RuntimeBehavior="win32App".

Приложения универсальной платформы Windows (uap10:RuntimeBehavior="windowsApp"UWP) также упаковываются; но этот раздел не относится к ним.

А затем атрибут uap10:TrustLevel (одного элемента application ) определяет, выполняется ли процесс упаковаемого приложения в контейнере приложения.

  • Приложение с полным доверием . Объявлен с uap10:TrustLevel="mediumIL".
  • Приложение appContainer . Объявлен с uap10:TrustLevel="appContainer". Выполняется в упрощенном контейнере приложений (поэтому изолируется с помощью файловой системы и виртуализации реестра). Дополнительные сведения см. в приложениях MSIX appContainer.

Это важно

Дополнительные сведения, зависимости и требования к возможностям см. в документации по этим двум атрибутам в Приложении. Также см. uap10, представленный в Windows 10 версии 2004 (10.0; Сборка 19041).

Назначение упаковки и контейнеров приложений

Цель упаковки приложения — присвоить ему идентификатор пакета во время выполнения. Удостоверение пакета необходимо для некоторых функций Windows (см. сведения о функциях, требующих удостоверения пакета). Вы можете упаковыть все сочетания типов приложений, описанных выше (и тем самым воспользоваться удостоверением пакета).

Но ключевой целью приложения appContainer является разделение состояния приложения от состояния системы как можно больше, при сохранении совместимости с другими приложениями. Windows достигает этого путем обнаружения и перенаправления определенных изменений, внесенных в файловую систему и реестр во время выполнения (известных как виртуализации). Мы будем отмечать, когда секция применяется только к виртуализированным приложениям.

Установка

Пакеты приложений устанавливаются для каждого пользователя вместо установки на уровне всей системы. Расположение по умолчанию для новых пакетов на новом компьютере находится в разделе C:\Program Files\WindowsApps\<package_full_name>с исполняемым файлом с именемapp_name.exe. Но пакеты могут быть установлены в других местах; Например, команды запуска Visual Studio используют команды проекта $(OutDir).

После развертывания файлы пакетов помечены только для чтения и сильно заблокированы операционной системой (ОС). Windows запрещает запуск приложений, если эти файлы были изменены.

Расположение C:\Program Files\WindowsApps — это то, что называется PackageVolume. Это типовое расположение, которое Windows предоставляет для PackageVolume; однако вы можете создать PackageVolume на любом диске и в любом каталоге. Кроме того, не все пакеты устанавливаются в PackageVolume (см. приведенный выше пример Visual Studio).

Файловая система

ОС поддерживает различные уровни операций файловой системы для упакованных классических приложений в зависимости от расположения папки.

Оптимизировано для устройства

Чтобы избежать дублирования файлов (для оптимизации дискового пространства и уменьшения пропускной способности, необходимой при скачивании файлов), ОС использует одно хранилище и жесткое связывание файлов. Когда пользователь загружает пакет MSIX, AppxManifest.xml используется для определения, существуют ли данные, содержащиеся в пакете, уже на диске после более ранней установки пакета. Если один и тот же файл существует в нескольких пакетах MSIX, ОС сохраняет общий файл только один раз и создает жесткие ссылки из обоих пакетов в общий файл. Так как файлы скачиваются в блоках по 64 Кб, даже если часть файла уже существует на диске, скачиваются только те части, которые отличаются. Это сокращает пропускную способность, используемую для скачивания.

Операции AppData в Windows 10 версии 1903 и более поздних версий

Этот раздел относится только к виртуализированным приложениям.

Все только что созданные файлы и папки в папке пользователя AppData (например, C:\Users\<user_name>\AppData) записываются в частное расположение для каждого пользователя, для каждого приложения, но объединяются во время выполнения, чтобы отображаться в реальном AppData расположении. Это обеспечивает некоторое разделение состояния для артефактов, которые используются только самим приложением; что позволяет системе очищать эти файлы при удалении приложения.

Изменения существующих файлов в папке пользователя AppData разрешены для обеспечения более высокой степени совместимости и взаимодействия между приложениями и ОС. Это уменьшает системный износ, так как ОС знает о каждом изменении файла или каталога, совершенных приложением. Разделение состояния также позволяет упакованным классическим приложениям продолжать работу с того места, на котором остановилась распакованная версия того же приложения. Обратите внимание, что ОС не поддерживает папку виртуальной файловой системы (VFS) для папки пользователя AppData .

Операции с данными AppData в операционных системах, выпущенных до Windows 10 версии 1903

Этот раздел относится только к виртуализированным приложениям.

Все записи в папку пользователя AppData (например, C:\Users\<user_name>\AppData), включая создание, удаление и обновление, копируются при их записи в отдельное место для каждого пользователя и приложения. Это создает иллюзию того, что упакованное приложение редактирует настоящее AppData, в то время как оно фактически модифицирует частную копию. Перенаправляя запись таким образом, система может отслеживать все изменения файлов, внесенные приложением. Это позволяет системе очищать эти файлы при удалении приложения, уменьшая системный "гниль" и обеспечивая более удобный интерфейс удаления приложений для пользователя.

Рабочий каталог и файлы приложений

Этот раздел относится только к виртуализированным приложениям.

Помимо перенаправления AppDataизвестные папки Windows (System32и Program Files (x86)т. д.) динамически объединяются с соответствующими каталогами в пакете приложения. Каждый пакет содержит папку с именем VFS в корневом каталоге. Все операции чтения каталогов или файлов в VFS каталоге объединяются во время выполнения со своими нативными аналогами. Например, приложение может содержать C:\Program Files\WindowsApps\<package_full_name>\VFS\SystemX86\vc10.dll как часть своего пакета, но файл будет установлен в C:\Windows\System32\vc10.dll. Это обеспечивает совместимость с классическими приложениями, которые ожидают, что файлы будут жить в расположениях, отличных от пакетов.

Запись в файлы и папки в пакете приложения не разрешена. Записи в файлы и папки, которые не являются частью пакета, игнорируются ОПЕРАЦИОННОй системой и разрешены до тех пор, пока пользователь имеет разрешение.

Распространенные операции файловой системы

В этой краткой справочной таблице показаны общие операции файловой системы и способы их обработки.

Операция Результат Пример
Чтение или перечисление известного файла или папки 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 и более поздних: новые файлы и папки, созданные в указанных ниже каталогах, перенаправляются в личное расположение для каждого пользователя и пакета.
  • Локальный
  • Local\Microsoft
  • Роуминг
  • Роуминг\Майкрософт
  • Роуминг\Microsoft\Windows\Пуск меню\Программы
В ответ на команду открытия файла ОС сначала откроет файл из расположения, специфичного для каждого пользователя и пакета. Если это расположение не существует, ОС попытается открыть файл из фактического местоположения 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 Общий 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\spool AppVSystem32Spool x86, amd64

Реестр

Этот раздел (и его подразделы) применяется только к виртуализированным приложениям.

Пакеты приложений содержат registry.dat файл, который служит логическим (виртуальным) эквивалентом HKLM\Software в реальном реестре. Во время выполнения виртуальный реестр объединяет содержимое этого куста с нативным системным кустом, чтобы предоставить единое представление обоих. Например, если registry.dat содержит один ключ Foo, то при чтении HKLM\Software во время выполнения он также будет содержать Foo (в дополнение ко всем собственным системным ключам).

Хотя пакеты MSIX включают ключи HKLM и HKCU , они обрабатываются по-разному. Только ключи в HKLM\Software являются частью пакета; Ключи в HKCU или других частях реестра не являются. Запись в ключи или значения в пакете не разрешена. Запись в ключи или значения, не входящие в пакет, разрешена до тех пор, пока у пользователя есть разрешение.

Все записи в HKCU копируются при попытке записи в частное расположение для каждого пользователя и каждой программы. Традиционно деинсталляторы не могут очистить HKEY_CURRENT_USER, поскольку данные реестра для вышедших из системы пользователей отключены и недоступны.

Все записи хранятся во время обновления пакета и удаляются только при удалении приложения полностью.

Общие операции реестра

Большая часть этого раздела относится только к виртуализированным приложениям.

В этой краткой справочной таблице показаны общие операции реестра и их обработка ОС.

Операция Результат Пример
Прочитать или перечислить HKLM\Software Динамическое объединение пакета hive с локальным эквивалентом системы. Если registry.dat содержит один ключ Foo, то во время выполнения чтение HKLM\Software отображает содержимое как HKLM\Software, так и HKLM\Software\Foo.
Записи в HKCU Копируется при записи в отдельное личное место для каждого пользователя и приложения. То же самое, что AppData и для файлов.
Записывает внутри упаковки. Запрещено. Пакет доступен только для чтения. Записи в HKLM\Software не допускаются, если соответствующий ключ/значение существует в кусте пакета.
Записывает за пределы пакета программы Игнорируется операционной системой. Разрешено, если у пользователя есть разрешения. Записи в HKLM\Software разрешены, если соответствующий ключ/значение не существует в разделе реестра пакета, и пользователь имеет соответствующие права доступа.

Деинсталляция

Этот раздел относится только к виртуализированным приложениям.

При удалении пакета пользователем все файлы и папки, расположенные в C:\Program Files\WindowsApps\<package_full_name>, удаляются, а также все перенаправленные записи в AppData или реестр, захваченные во время процесса упаковки.