UWP приложение и Desktop .NET Framework. Совмещаем несовместимое

💡 Усі статті, обговорення, новини про .NET — в одному місці. Приєднуйтесь до .NET спільноти!

Привет.

В данной статье хочу рассказать о приеме, который поможет совместить все достоинства платформы UWP и функциональность .Net Framework.

Но для начала обрисую проблематику.

UWP платформа является наследницей WinRT, которая была запущена с выходом Windows 8 с «плиточным интерфейсом». Но полноценному переходу на новые рельсы мешает невозможность использования старых .Net библиотек, коих написано великое множество, и которые заняли прочное место в разработках. Плюс ограничение самой платформы: «туда ходи, сюда не ходи» :). В UWP платформе мы можем использовать лишь то, что Microsoft посчитал безопасным и что можно портировать на другие платформы.

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

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

Компьютер работает на Windows 10, стал вопрос написания приложений. Зная, что UWP мне не подходит по причине того, что приложения не умеют полноценно работать с файловой системой, управлять службами, использовать VLC, я попробовал сделать WPF приложение.

Сразу скажу, компьютер не шибко сильный. Внутри Intel Atom Z3750, 2GB оперативной памяти и 32GB SSD. А приложение хотелось сделать так, чтоб на него приятно было смотреть: анимированные иконки, анимации при переходе между окнами, голосовое сопровождение и адаптация под touch. Когда сделал прототип пользовательского интерфейса сразу стало ясно, из WPF ничего хорошего не получится, анимации подтормаживали, а с touch совсем беда: он вроде, как и есть, но отрабатывает ужасно медленно.

Переписал прототип интерфейса под UWP — и все поехало :) Это не удивительно, т.к. UWP приложения используют .Net native. Соответственно приложение компилируется в native код, а пользовательский интерфейс ускоряется DirectX-ом.

Другой пример из жизни моего заказчика. Проблематика похожая: нужно было разработать приложение, которое должно было запускаться на дешевом планшете, с поддержкой touch, но с определенными особенностями: использование локальной базы SQL Server Compact, возможность отправки писем используя локальный outlook клиент и т.д. Этим приложением должны пользоваться консультанты в магазинах, соответственно необходимо обеспечить централизованное обновление, вход используя учетную запись AD и прочее.

Собственно, вопрос, который я начал исследовать был следующий: а можно ли совместить достоинства обеих платформ (UWP + Classic .Net)?

Поиски привели меня на White Paper: Brokered Windows Runtime Components for side-loaded Windows Store apps

Для начала давайте расшифруем некоторые понятия:

Side-loaded Windows Store apps. С релизом Windows 8 появился магазин приложений как единая точка загрузки WinRT приложений. Закачивая приложения с магазина можно не переживать, что оно не будет работать (такие случаи бывают, но очень редко) или содержит вирусы. Публикуя приложения в магазин, они становятся видимыми и доступными всем в тех регионах, которые Вы указываете при публикации приложений. Но есть сценарии, когда необходимо иметь механизм дистрибуции приложений только определенным пользователям, при этом для остальных — приложение должно быть не видимым. Если конкретнее, это LOB (Line Of Business) приложения, которые организации разрабатывают для внутреннего использования. Есть 2 варианта как поступить в данной ситуации:

1. Использовать Windows Store for Business для создания собственных приватных магазинов приложений, доступ к которым будут иметь только определенные аккаунты. При этом приложения будут проходить некую упрощенную процедуру сертификации и обновления приложений.
2. Не использовать магазин приложений вообще. Для установки приложения конкретному пользователю можно использовать powershell скрипт, который генерится при публикации приложения локально из Visual Studio. Для дистрибуции приложения всем пользователям, можно встроить его в образ корпоративной ОС используя DISM. Так же можно использовать (и это, наверное, самый правильный вариант) System Center Configuration Manager для доставки приложений на пользовательские ПК.

Что же касается деплоймента Windows 10 приложений, концепция та же, за исключением появления Microsoft Deployment Toolkit для доставки подготовленных образов ОС.

Детали по вариантам разворачивания Windows 10 приложений можно почитать тут.

Вернемся же к вопросам разработки и определим, что такое Brokered Windows Runtime Components

На конференции //Build 2014 вместе с апдейтом Windows 8.1 был так же объявлен функционал для коммуникации между приложением Windows Store и Desktop процессами. Весь этот запутанный механизм и описан в White Paper, ссылку на который я дал выше. Этот функционал имеет название «Inter Process Communication», или сокращенно «IPC».

Появились дальше официальные семплы приложений.

Если в вкратце, то суть подхода Brokered WinRT состоит в следующем:

• Есть компонента — Client, которая является нашим WinRT приложением.
• Есть компонента — Server, что есть самая обыкновенная .Net библиотека
• И есть компонента — Рroxy, написанная на C++, которая является брокером между нашим клиентом и сервером и занимается транслированием сообщений от клиента к серверу и наоборот.

В официальные семплы я было дело полез, но быстрого результата не добился (такая натура, хочется все и сразу :))

Продолжив поиски наткнулся на доклад Harry Pierson на все том же //Build 2014. Он показывал демо, как раз то, что мне нужно! Семпл, который он показывал лежит тут, а тут описательная статья, объясняющая шаг за шагом, как все насетапить.

Ну и апогей, готовый темплейт проекта в Visual Studio Gallery, который все сделает сам :)

И все было бы хорошо, если бы не Windows 8. Я-то хочу делать под Windows 10!

Логические рассуждения навели меня на мысль, что наверняка десятка должна поддерживать этот сценарий, и я попробовал сделать все так, как это делалось в восьмерке. Черта с два.

И вот, прошло совсем немного времени, и я наколупал эту статью. Сделал все, как там написано и о чудо! Все заработало. Ну а после ребята выпустили и темплейт проекта, который теперь красуется на GitHub и в Visual Studio Gallery.

Ну что же, счастье есть, давайте попробуем поиспользовать сие чудо.

Для этого нам необходимо:
• Установить бесплатную редакцию Visual Studio 2015 Community или любую платную.
• Windows 10 SDK (обычно ставится вместе с Visual Studio)
• Скачать и установить сам темплейт из Visual Studio Gallery

Далее фактически нужно сделать все, что перечислено в этой статье:

1. Открыть Visual Studio (весь сценарий у меня работал только в случае запущенной студии с правами администратора. Это не описано в оригинальной статье.)

2. В диалоге создания нового проекта, в поиске необходимо вбить «Brokered Component Solution»

3. Вбить имя нашего проекта, нажать «ОК» и в открывшемся окне указать названия проектов для Клиента, Сервера и Прокси (я оставлял как есть)

После нажатия кнопки «OK», генерилось решение с 3мя проектами.

Теперь важно все сделать в правильной последовательности:

4. Собрать серверный проект. Он сгенерит необходимые файлы для прокси проекта.

5. Кликнуть правой кнопкой мыши по Proxy проекту и выбрать пункт «Add existing items» и добавить файлы, сгенерированные на предыдущем шаге (dlldata.c, server_i.c, server_p.c, server.h)

6. Собрать Proxy проект.

7. Кликнуть правой кнопкой мыши по Client проекту и выбрать «Add new reference». В диалоге подключения библиотек необходимо добавить «server.winmd» (должен быть примерно тут: Server\Bin\Debug\Reference\Server.winmd)

8. Кликнуть правой кнопкой мыши по Client проекту и в контекстном меню выбрать «Set as startup project»

9. Жмем F5 для запуска приложения.

Если Вы все сделали правильно, то при нажатии на кнопку «Click here to invoke component» Вы должны получить результат выполнения метода в Server библиотеке.

Что же мы получили в итоге?

Фактически, мы дополнили функционал UWP приложения и получили возможность использования силу 2х технологий: Понятный дизайн и хорошая производительность пользовательского интерфейса, готовые компоненты для использования камеры, геолокации, авторизации, живых тайлов и Push сообщений, в общем, все то, что дает UWP + за счет использования Desktop .Net Framework мы получаем все то, чего нам не хватает для нашего приложения.

И все-таки, в этой бочке меда есть ложка дегтя: как только мы начинаем работать с Desktop .Net Framework, ни о какой переносимости приложений на мобильные платформы, IoT или Xbox речи идти не может. Такие приложения будут работать только на ПК с полновесной Windows.

Ну и напоследок, интересный материал по использованию этого подхода при разработке реальных приложений.