Примечание. Очень важно использовать в неопубликованном приложении ссылочный winmd-файл. Правила, применяемые после сборки в приложении сервера IPC (дополнительные сведения см. в следующем разделе), аккуратно разделяют эти два winmd-файла, помещая их в разные каталоги.

Загрузка неопубликованного приложения является важнейшей составляющей этой функциональности. Поэтому модель загрузки неопубликованных приложений — это одновременно и требование возможных пользователей компонента, и критически важное условие его реализации. Она предусматривает включение в классический компонент существующих бизнес-правил — например, из SQL Server.

Предполагается, что «модель» полностью содержится в классическом компоненте. Из этого сразу становится понятно, что классический компонент будет «без монитора» (т.е. в нем не будет пользовательского интерфейса). Представление целиком содержится в неопубликованном корпоративном приложении. И хотя нет требований, связанных с включением в это приложение конструкции «модель представления», мы предполагаем, что использование такого шаблона станет общепринятым.

Компоненты среды выполнения Windows для неопубликованных приложений Магазина Windows, выполняемые через посредника

Неопубликованное приложение— это обычное приложение UWP, которое имеет только одну особенность: в отличие от приложений, устанавливаемых через Магазин Windows, оно загружается без публикации. Рекомендуется, чтобы неопубликованное приложение прошло сертификационный тест WACK (соответствующий инструмент находится в меню «Проект» > «Магазин» Visual Studio). Важно помнить, что механизм брокера приложений, предоставляемый в составе Windows10, является 32-разрядным.

Неопубликованные приложения могут быть 64-разрядными (при условии, что зарегистрированы 64- и 32-разрядные прокси), но это будет нетипичная ситуация. Код сервера выполняется в одном домене приложения.

Чтобы их аккуратно разделить, компоненты версий 1.1 и 2 помещаются в разные каталоги сервера, а затем приложению задается тот экземпляр сервера, который поддерживает нужную версию компонента. Реализацию серверного кода могут использовать несколько экземпляров сервера брокера приложений. Для этого нескольким приложениям задается один и тот же каталог сервера.

Первый шаг в создании приложения с использованием этой функциональности— это создание контракта между неопубликованным приложением и классическим компонентом. Это необходимо делать исключительно с использованием типов среды выполнения Windows. Создавать проект необходимо с использованием шаблона «Библиотека классов», а не шаблона «Компонент среды выполнения Windows». Этот код определяет класс EnterpriseServer, экземпляры которого можно создавать из неопубликованного приложения.

Шаг 2. Отредактируйте файл проекта вручную, чтобы изменить тип вывода проекта на компонент среды выполнения Windows. В открытом файле найдите тег и измените его значение на “winmdobj”. Шаг 5. Создайте правило сборки, которое создает файл метаданных Windows с реализацией, т.е. содержащий не только те же метаданные, но и реализацию.

Примечание. Сценарий будет разным в зависимости от версии Windows, на которую нацелен проект (Windows10), и от используемой версии Visual Studio. Структура проекта, определенная приведенными выше правилами сборки, обеспечивает размещение ссылочного winmd-файла и аналогичного файла с реализацией в разных каталогах во избежание путаницы. Это позволяет приложению просто создать новый объект для доступа к функциональности классического компонента.

Содержимое этого объявления в манифесте приложения одинаковое для всех приложений, нацеленных на Windows10. В качестве категории выбрана inProcessServer, так как в категории outOfProcessServer есть несколько записей, неприменимых к этой конфигурации приложения. Атрибут Value указывает расположение WINMD-файла реализации классического компонента (дополнительную информацию о нем см. в следующем разделе).

Как указывалось в разделе «Определение контракта», ссылка на проект должна быть включена в ссылочный WINMD-файл классического компонента. Ссылочный winmd-файл вручную копируется в этот каталог второго уровня.

Создание и развертывание прокси среды выполнения Windows

После этого принадлежащее классическому компоненту пространство имен верхнего уровня (например, Fabrikam) должно появиться в качестве узла верхнего уровня в части проекта «Ссылки». Если вы случайно перенесете в каталог неопубликованного приложения winmd-файл с реализацией и сошлетесь на него, вы скорее всего получите ошибку «не удается найти IStringable».

В предыдущих двух разделах описано объявление класса и механизма переноса ссылочного winmd-файла в проект неопубликованного приложения. Основная часть оставшейся работы с классическим компонентом заключается в реализации. Один предназначен для классических приложений («.NetFramework»), а второй нацелен на часть среды CLR для приложений UWP («.NetCore»).

Раздел совпадает с настоящим RuntimeClass, который используется внутри процесса и предпочтителен для компонента среды выполнения Windows в пакете приложения. Примечание. На данный момент в контракте компонентов среды выполнения Windows между классическим компонентом и неопубликованным приложением не поддерживаются перечисления. В Windows появилась новая функциональность, получившая название работающих через брокер компонентов среды выполнения Windows для неопубликованных приложений.