Бөлісу құралы:

Межпроцессное взаимодействие (IPC)

В этом разделе описаны различные способы взаимодействия между приложениями универсальной платформы Windows (UWP) и приложениями Win32.

Службы приложений

Службы приложений позволяют приложениям предоставлять службы, принимаюющие и возвращающие пакеты свойств примитивов (ValueSet) в фоновом режиме. Расширенные объекты можно передавать, если они сериализованные.

Службы приложений могут выполняться либо вне процесса как фоновая задача, либо в процессе в приложении, работающем в переднем плане.

Службы приложений лучше всего использовать для совместного использования небольших объемов данных, где не требуется задержка, близкая к реальному времени.

КОМ

COM — это распределенная объектно-ориентированная система для создания двоичных компонентов программного обеспечения, которые могут общаться и взаимодействовать. Разработчик использует COM для создания повторно используемых компонентов программного обеспечения и уровней автоматизации для приложения. Компоненты COM могут находиться в процессе или вне процесса, и они могут взаимодействовать с помощью клиентской и серверной модели. Внепроцессные COM-серверы уже давно используются в качестве средства для обмена данными между объектами.

Упакованные приложения с возможностью runFullTrust могут регистрировать внепроцессные серверы COM для IPC, используя манифест пакета . Это называется упакованным COM.

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

Широкий доступ к файловой системе

Упакованные приложения могут выполнять IPC с помощью широкой файловой системы, объявляя возможность broadFileSystemAccess ограниченной. Эта возможность предоставляет API-интерфейсы Windows.Storage и xxxFromApp API Win32 доступ к широкой файловой системе.

По умолчанию IPC через файловую систему для упакованных приложений ограничен другими механизмами, описанными в этом разделе.

PublisherCacheFolder

PublisherCacheFolder позволяет упакованным приложениям объявлять папки в манифесте, к которым можно предоставить общий доступ другим пакетам того же издателя.

Общая папка хранилища имеет следующие требования и ограничения:

  • Данные в общей папке хранилища не резервируются или перемещаются.
  • Пользователь может очистить содержимое общей папки хранилища.
  • Общую папку хранилища нельзя использовать для совместного использования данных между приложениями из разных издателей.
  • Вы не можете использовать общую папку хранилища для совместного использования данных между разными пользователями.
  • В общей папке хранилища нет управления версиями.

Если вы публикуете несколько приложений и ищете простой механизм для обмена данными между ними, то PublisherCacheFolder — это простой вариант на основе файловой системы.

Управляющий хранилищем с общим доступом

SharedAccessStorageManager используется в сочетании со службами приложений, активациями протокола (например, LaunchUriForResultsAsync) и т. д., чтобы предоставить общий доступ к StorageFiles через токены.

FullTrustProcessLauncher

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

В случаях, когда ограничения пакетов становятся бременем или отсутствуют подходящие варианты IPC, приложение может использовать процесс полного доверия как посредника для взаимодействия с системой. Затем оно может взаимодействовать с этим процессом полного доверия через службы приложений или другой поддерживаемый механизм IPC.

LaunchUriForResultsAsync

LaunchUriForResultsAsync используется для простого обмена данными (ValueSet) с другими упакованными приложениями, реализующими контракт активации ProtocolForResults . В отличие от служб приложений, которые обычно выполняются в фоновом режиме, целевое приложение запускается на переднем плане.

Файлы можно совместно использовать, передав маркеры SharedStorageAccessManager в приложение через ValueSet.

Обратная петля

Loopback — это процесс взаимодействия с сетевым сервером, прослушивающим localhost (адрес обратного цикла).

Для обеспечения безопасности и сетевой изоляции локальные соединения для IPC по умолчанию блокируются для упакованных приложений. Можно включить подключения обратного цикла между доверенными упакованными приложениями, используя возможности и и свойства манифеста .

  • Все упакованные приложения, участвующие в возвратных соединениях, должны объявить возможность privateNetworkClientServer в своих манифестах пакетов .
  • Два упакованных приложения могут взаимодействовать через loopback, объявив LoopbackAccessRules в манифестах пакета.
    • Каждое приложение должно перечислить другое в LoopbackAccessRules. Клиент объявляет правило «out» для сервера, а сервер объявляет правила «in» для поддерживаемых клиентов.

Замечание

Имя семейства пакетов, необходимое для идентификации приложения в этих правилах, можно найти с помощью редактора манифеста пакета в Visual Studio во время разработки, через Центр Партнеров для приложений, опубликованных в Microsoft Store, или с помощью команды PowerShell Get-AppxPackage для уже установленных приложений.

Непакованные приложения и службы не имеют удостоверения пакета, поэтому их нельзя объявить в LoopbackAccessRules. Вы можете настроить упакованное приложение для подключения через loopback с распакованными приложениями и службами с помощью CheckNetIsolation.exe, однако это возможно только для сценариев установки вне магазина или отладки, где у вас есть локальный доступ к компьютеру и права администратора.

  • Все упакованные приложения, участвующие в обратных соединениях, должны объявить возможность privateNetworkClientServer в своих манифестах пакетов .
  • Если упакованное приложение подключается к неупакованному приложению или службе, выполните команду CheckNetIsolation.exe LoopbackExempt -a -n=<PACKAGEFAMILYNAME>, чтобы добавить исключение обратного соединения для упакованного приложения.
  • Если неупакованное приложение или служба подключается к упакованному приложению, запустите CheckNetIsolation.exe LoopbackExempt -is -n=<PACKAGEFAMILYNAME>, чтобы разрешить упакованному приложению получать входящие подключения с обратной связью.
    • CheckNetIsolation.exe должен выполняться непрерывно, пока упакованое приложение прослушивает подключения.
    • Флаг -is появился в Windows 10 версии 1607 (10.0; Сборка 14393).

Замечание

Имя семейства пакетов, необходимое для флага -nCheckNetIsolation.exe, можно найти в редакторе манифеста пакетов в Visual Studio во время разработки, в Центре партнеров для приложений, опубликованных в Microsoft Store, или с помощью команды Get-AppxPackage в PowerShell для уже установленных приложений.

CheckNetIsolation.exe также полезно для отладки проблем сетевой изоляции.

Трубы

Каналы обеспечивают простой обмен информацией между сервером канала и одним или несколькими клиентами канала.

Анонимные каналы и именованные каналы поддерживаются со следующими ограничениями:

  • По умолчанию именованные каналы в упакованных приложениях поддерживаются только между процессами в одном пакете, если процесс не является полным доверием.
  • Именованные каналы можно совместно использовать между пакетами, следуя рекомендациям по совместному использованию именованных объектов.
  • Именованные каналы (в упакованных и распакованных приложениях) должны использовать синтаксис \\.\pipe\LOCAL\ для имени канала.

Реестр

Использование реестра для IPC обычно не рекомендуется, но поддерживается для существующего кода. Упакованные приложения могут получить доступ только к разделам реестра, к которым у них есть разрешение на доступ.

Обычно упакованные классические приложения (см. создание пакета MSIX из кода) используют виртуализацию реестра, так что глобальные записи реестра сводятся к частному кусту в пакете MSIX. Это обеспечивает совместимость исходного кода при минимизации влияния глобального реестра и может использоваться для IPC между процессами в одном пакете. Если вы должны использовать реестр, предпочтительно пользоваться этой моделью, а не манипулировать глобальным реестром.

RPC

RPC можно использовать для подключения упакованного приложения к конечной точке RPC Win32, если упакованное приложение имеет правильные возможности для сопоставления списков контроля доступа в конечной точке RPC.

Пользовательские возможности позволяют изготовителям оборудования и IHV определять произвольные возможности, ACL конечных точек RPC с ними, а затем предоставить эти возможности авторизованным клиентским приложениям. Полный пример приложения см. в примере CustomCapability .

Конечные точки RPC также могут включаться в список контроля доступа для определенных пакетированных приложений, чтобы ограничить доступ к конечной точке только для этих приложений, без необходимости управления пользовательскими возможностями. Для получения идентификатора безопасности (SID) из имени семейства пакетов можно использовать API DeriveAppContainerSidFromAppContainerName, а затем назначить права доступа для конечной точки RPC с использованием этого идентификатора безопасности, как показано в примере CustomCapability.

Общая память

Сопоставление файлов можно использовать для совместного использования файла или памяти между двумя или несколькими процессами со следующими ограничениями:

  • По умолчанию сопоставления файлов в упакованных приложениях поддерживаются только между процессами в одном пакете, если только процесс не обладает полным доверием.
  • Сопоставления файлов можно совместно использовать в пакетах, следуя рекомендациям по совместному использованию именованных объектов.

Рекомендуется использовать общую память для эффективного совместного использования и управления большими объемами данных.

  • Last updated on