Read this article in your language IT | EN | DE | ES
В этом посте рассмотрим возможность Desktop Bridge: в частности, о перемещение бизнесс-логики на Windows Runtime Components, также известные как WinRT Components. Раньше Windows поддерживала только вызываемую ОС, обусловленную WinRT компонентами из Win32 приложений. Любая попытка вызвать пользовательские (так называемые сторонние) WinRT компоненты не выполнялась, потому что приложение Win32 не имеет идентификатора пакета и, следовательно, не было способа зарегистрировать компонент с системой во время установки или каким-либо образом найти подходящий компонент для выполнения.
Эти ограничения были устранены, так как приложения Win32 на Desktop Bridge могут быть индивидуальны и зарегистрированы в ОС, включая любые Windows Runtime Components, входящие в состав пакета. В Windows 10 Fall Creators Update, Desktop Bridge поддерживает эту функциональность, включая поддержку как для In-Process Servers, так и Out-Of-Process Servers.
Обмен кодами - Чем WinRT Components лучше других параметров
Существует много разных способов совместного использования кода в приложении, поэтому выбранный вами вариант напрямую зависит от ваших сценариев. На профессиональном уровне существует несколько способов, которые связывают UWP и Desktop Bridge:
- DLL - для сценариев, требующих производительности proc кода и не требующих межязыковой совместимости
- WinRT Components – для межъязыковой совместимости или поддержки внепроцессной активации для надежности
- .Net library – для сценариев, которые работают в proc, и всех клиентов, управляемыми разработчиками, включая PCL или .Net Standard libraries
Создание нового или движущегося кода в Windows Runtime Component позволяет повторно использовать код между процессами AppContainer и Win32 в одном пакете. В то время как вы повторно используете существующие библиотеки DLL в вашем процессе AppContainer, вызывая LoadPackageLibrary, переходя к Windows Runtime Component, вы получаете доступ к повторному использованию из-за лучшей совместимости языков (Native C / C ++, управляемый код с C # & VB и Javascript), а также интеграцию Visual Studio через Все ваши проекты. Кроме того, компоненты WinRT поддерживают модель активации вне процесса, которая обеспечивает надежность для вашего приложения.
Как это работает?
Поскольку приложения на Desktop Bridge имеют манифест, записи регистрации для WinRT Component такие же, как и для UWP приложения, с использованием расширений InProcessServer и OutOfProcessServer. Эти расширения регистрируют ActivatableClassId и его бинарную реализацию с вашим пакетом, поэтому, когда ваше приложение пытается активировать класс, система может его найти.
In-Process Servers
Эта функция позволяет разработчикам легко обмениваться кодами между Win32 и UWP приложениями, запущенными в AppContainer, которые могут быть загружены через In-Proc. Компонент построен таким образом, к примеру: Создайте новый проект WinRT Component в VS и его регистрация в манифесте будет точно такой же, как и для внутренних серверов UWP. Поскольку не требуется никакого изменения схемы манифеста, разработчики могут использовать существующие наборы инструментов в VS2015 или VS2017 для сборки In-Proc серверов, но это может быть выполнено только на устройстве с обновлением Fall Creators Update.
Ниже приведен пример регистрации в процессе для C++ WinRT Component, где CPPSimpleMathWinRT.dll является родной реализацией класса SimpleMath.
<Extension Category="windows.activatableClass.inProcessServer">
<InProcessServer>
<Path>CPPSimpleMathWinRT.dll</Path>
<ActivatableClass ActivatableClassId="SimpleMathWinRT.SimpleMath" ThreadingModel="both" />
</InProcessServer>
</Extension>
Ниже вы увидите простой пример Winforms Calculator, который использует C++ WinRT Component для его математического движка.
Как это выглядит во время выполнения:
Пример с C++/CX WinRT Component: https://github.com/Microsoft/DesktopBridgeToUWP-Samples/tree/master/Samples/WinFormsWinRTComponent
Пример с C# WinRT Component: https://github.com/Microsoft/DesktopBridgeToUWP-Samples/tree/master/Samples/WinformsManagedWinRTComponent
Out-Of-Process servers
Регистрация OOP-сервера для приложения с использованием расширений Desktop Bridge очень знакома разработчикам, которые ранее регистрировали серверы в UWP. Тем не менее, есть нюансы и ограничения, о которых нужно знать. Так как OOP серверы позволяют вам обмениваться кодами между процессами Win32 и AppContainer, существуют ограничения для совместного использования данных между клиентами - это отражается на модели сервера. Все зависит от потребностей вашего приложения в отношении того, какую модель стимулирования вы должны использовать.
Инстинктивное поведение сервера определяется требованиями символического процесса, независимо от того, вызывается ли процесс NTCompareToken () и работает ли экземпляр сервера правильно. Если они совпадают, то используется существующий экземпляр сервера. Если они разные, то запускается новый экземпляр сервера.
Одно из ключевых требований - идентификация приложения. Приложения в UWP определены в манифесте, а в большинстве UWP приложений, опубликованных в Windows Store, существует только одно приложение. Но на Desktop Bridge у вас может быть несколько. Еще одним ключевым требованием является уровень доверия вызывающего процесса. На Desktop Bridge, пакет объявлен с возможностью runFullTrust, <rescap:Capability Name=”runFullTrust” />, который позволяет одному или нескольким приложениям быть объявлеными с FullTrust entrypoint, EntryPoint=”Windows.FullTrustApplication”. Приложения, использующие FullTrust entrypoint, могут вызывать любой API, который им нужен. Обычно это основной исполняемый файл Win32 / .Net.
Microsoft ссылаются на эти приложения как на приложения FullTrust.
Если у вас нет этой точки входа, приложение работает на более низком уровне доверия, называемом Base Trust, и имеет дополнительные ограничения в изолированной среде под названием AppContainer, что характерно для приложения при создании приложения UWP в Visual Studio. Эти разные уровни доверия приводят к различным требованиям к признакам процесса, и в результате - к другому экземпляру сервера. Эта модель называется ActivateAsActivator или AAA. Ниже приведен пример этой регистрации, и вы заметите, что это то же самое, что и для UWP приложения; нет ничего нового для использования этой инстинктивной модели для доступа к серверу из вашего Win32 кода:
<Extension Category="windows.activatableClass.outOfProcessServer">
<OutOfProcessServer ServerName="Microsoft.SDKSamples.Kitchen.OvenServer" >
<Path>Microsoft.SDKSamples.Kitchen.exe</Path>
<Instancing>singleInstance</Instancing>
<ActivatableClass ActivatableClassId="Microsoft.SDKSamples.Kitchen.Oven" />
</OutOfProcessServer>
</Extension>
В то время как модель ActivateAsActivator позволяет обмениваться кодами, создание отдельного экземпляра сервера для каждого клиента может быть немного сложнее. Чтобы облегчить процесс, UWP представил концепцию ActivateAsPackage (AAP), которая обеспечивает одинаковое поведение для серверов в пакете. Это отображено в новом атрибуте IdentityType=”activateAsPackage” в элементе <OutOfProcessServer>.
Однако существует ограничение в модели AAP, так как вы должны указать, в какой границе доверия вы хотите запустить сервер. Сервер должен быть зарегистрирован для использования процессами AppContainer или FullTrust. Если вы хотите использовать сервер как в процессах FullTrust, так и в AppContainer, вам нужно будет создать и зарегистрировать два сервера с отдельными именами серверов и именами классов, поскольку эти имена должны быть уникальными для каждого пакета. Чтобы зарегистрировать сервер для использования в процессе FullTrust, был добавлен новый атрибут RunFullTrust=”true”. Если вы хотите, чтобы сервер использовался в ваших AppContainer процессах, пропустите данный атрибут.
Оба новых атрибута находятся в пространстве имен xmlns:uap5=”http://schemas.microsoft.com/appx/manifest/uap/windows10/5”. Ниже приведен пример регистрации, показывающий регистрацию Win32 и UWP серверов:
AAP Регистрация сервера для использования процесса Win32, также известного как FullTrust:
<Extension Category="windows.activatableClass.outOfProcessServer">
<OutOfProcessServer ServerName="Microsoft.SDKSamples.Kitchen.OvenServer" uap5:IdentityType="activateAsPackage" uap5:RunFullTrust="true">
<Path>Microsoft.SDKSamples.Kitchen.exe</Path>
<Instancing>singleInstance</Instancing>
<ActivatableClass ActivatableClassId="Microsoft.SDKSamples.Kitchen.Oven" />
</OutOfProcessServer>
</Extension>
AAP-регистрация сервера для использования UWP процессами:
<Extension Category="windows.activatableClass.outOfProcessServer">
<OutOfProcessServer ServerName="Microsoft.SDKSamples.Kitchen.OvenServerUWP" uap5:IdentityType="activateAsPackage">
<Path>Microsoft.SDKSamples.KitchenUWP.exe</Path>
<Instancing>singleInstance</Instancing>
<ActivatableClass ActivatableClassId="Microsoft.SDKSamples.Kitchen.OvenUWP" />
</OutOfProcessServer>
</Extension>
Образец использует AAP сценарий и показывает два приложения C # Winforms с использованием OOP WinRT Component, в результате чего выполняется только один экземпляр исполняемого файла сервера. WinRT Component представляет собой модифицированную версию образца WRLOutOfProcessWinRTComponent из Universal Windows Samples на github. В этом примере оба клиента вызывают сервер и BakeBread () метод. Из TaskManager можно увидеть, что существует только один экземпляр Сервера.
Ссылка GitHub: https://github.com/Microsoft/DesktopBridgeToUWP-Samples/tree/master/Samples/WinformsOutOfProcessWinRTComponent
Поддержка Visual Studio
В проектах, созданных для этого решения, стоит выделить пару деталей и обходные пути. Прежде всего, Visual Studio в настоящее время не позволяет добавлять ссылки на проекты из проекта WinRT Component в проект Win32 / .Net. Вы можете обойти это, выгрузив проект Win32 / .Net и добавив ссылку на проект прямо в файл проекта, например:
<ItemGroup>
<ProjectReference Include="..\Server\WRLOutOfProcessWinRTComponent_server.vcxproj" />
</ItemGroup>
Хотя это добавляет ссылку, вы увидите предупреждение в Visual Studio, поскольку ранее это не поддерживалось. Microsoft продолжает работать с Visual Studio, чтобы улучшать его с каждой новой версией, но пока вы можете игнорировать предупреждение.
Во-вторых, образцы используют UWP JavaScript проект для обработки упаковки приложения. Этот метод отмечен в документе Desktop Bridge Packaging с документацией Visual Studio и работает как разумное решение, до тех пор пока Visual Studio не добавит поддержку. Преимущество этого подхода заключается в том, что вы можете добавить ссылку с вашего компонента WinRT в проект JavaScript, а затем система сборки Visual Studio добавляет соответствующие регистрации для зависимостей пакетов, включая VCLib и .NetNative, а также расширения <InProcessServer>. Visual Studio не поддерживает добавление регистраций <OutOfProcessServer>, поэтому вам нужно будет добавить их в манифест вручную.
Сборка на основе метаданных - никаких Proxy/Stub DLL!
Наконец-то, в примере <OutOfProcessServer> используются приемущества сборки на основе метаданных (Metadata Based Marshaling), которая была представлена в обновлении Windows 10 Anniversary Update (Windows 10 version 1607). Эта функция не привлекла большого внимания, но она позволяет WinRT Component разработчикам не создавать класс proxy / stub, экономя их время и усилия. Это возможно, потому что WinMD развертывается с приложением, и, таким образом, система может идентифицировать и собирать типы кросс-процессов для разработчика. Вы заметите, что код сервера в этом примере не включает прокси-проект и бинарные файлы.
Вывод
Благодаря Windows Runtime Components и Desktop Bridge разработчики могут сделать еще один шаг на пути к переносу бизнес-логики в UWP. Windows Runtime Components обеспечивают повторное использование кода, которое может работать как с процессами FullTrust, так и с процессами UWP, и они позволяют использовать более широкий межпеременный язык.
Для получения дополнительной информации о Desktop Bridge, перейдите на Windows Dev Center.
Ваше приложение уже готово к публикации в Windows Store? Дайте нам знать!
Exception: Collection was modified after the enumerator was instantiated.