Posted on 6. December 2017

Visual Studio Application Packaging Project

Visual Studio 2017 15.4 представил новый проект Windows Application Packaging, который поможет Вам модернизировать Ваше приложение с помощью нового стека развертывания Windows 10 приложений (Windows 10 App Deployment Stack).

Microsoft рассказывали об этом в предыдущей статье: Visual Studio 2017 Update 4 упрощает модернизацию Вашего приложения и делает его готовым к публикации, и сегодня Microsoft представит Вам новые возможности Visual Studio 2017 15.5, которые позволяют создавать новые сценарии для проекта упаковки Windows приложений с использованием всех преимуществ Windows 10 функций в Ваших приложениях.

В этой статье будут рассматриватся три примера, которые подчеркнут новые возможности, добавленные в проект упаковки, чтобы обеспечить упаковку не только для Win32 приложений, но и для приложений и UWP компонентов:

  1. Фоновое выполнение с использованием фоновых задач UWP.
  2. Интеграция Windows Shell с использованием соглашения о совместном использовании.
  3. Добавление инвестиций Win32 кода в пакеты UWP приложений.

Первые два примера это уже существующие WPF приложения, упакованные как APPX с расширенным функционалом, который реализован как UWP компоненты. Первое приложение добавляет фоновое исполнение на основе фоновых UWP задач, а второе приложение показывает, как активно внедрять приложение с Windows 10 оболочкой, используя функцию в виде соглашения о совместном использовании (Share contracts). В заключение, последнее приложение - это точка входа в UWP, вызывающая классический Win32 процесс, который взаимодействует с Excel.

Обратите внимание: Поскольку UWP компоненты необходимо скомпилировать для определенной платформы: x86 или x64, конфигурация любого конфигурационного решения для любого процессора не будет работать ни в одном из этих образцов.

Все образцы доступны в отчетах на GitHub, разделе Windows-Packaging-Samples. Для этих образцов требуется Visual Studio 2017 15.5 Preview 4 или выше, доступный для загрузки с https://www.visualstudio.com/downloads.

  1. WPF с Фоновыми Задачами

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

Чтобы показать, как использовать эту функцию в Ваших Win32 приложениях, Microsoft собирается реализовать небольшую утилиту, которая сделает HTTP-запрос к URL-адресу, настроенному пользователем, и покажет прошедшие миллисекунды в всплывающих уведомлениях (Toast Notification).

Microsoft создадаст WPF приложение, чтобы пользователь мог указывать URL-адрес для проверки и включения / выключения фоновых задач. Фоновая задача будет реализована как Windows Runtime Component (WINMD). Чтобы включить этот компонент в пакет, нужно создать UWP приложение, которое использует этот компонент, и, наконец, добавить WPF и UWP проекты в качестве ссылок на проект упаковки. Ниже приведен список необходимых шагов.

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

  1. Упакуйте Ваше настольное приложение, используя проект упаковки
  2. Добавьте Runtime Windows компонент для выполнения фоновой задачи
  3. Добавьте UWP приложение, которое ссылается на компонент времени выполнения
  4. Добавить ссылку на UWP приложение из проекта упаковки
  5. Настройте Фоновую задачу в манифесте
  6. Зарегистрируйте фоновую задачу из Настольного приложения

После завершения 1-4 шагов, у Вас должно быть решение для проектов, как показано на рисунке ниже:

Проект упаковки ссылается не только на WPF приложение, но и на UWP проект. По этой причине решение должно быть настроено для конкретной платформы, поскольку UWP недоступен для любых конфигураций ЦП.

Реализация Фоновых Задач

Фоновая задача - это класс C#, который реализует интерфейс IBackgroundTask. Этот интерфейс определяет Run метод, который будет вызываться, когда система запустит задачу.

public sealed class SiteVerifier : IBackgroundTask
{
    public async void Run(IBackgroundTaskInstance taskInstance)
    {
 
        taskInstance.Canceled += TaskInstance_Canceled;
        BackgroundTaskDeferral deferral = taskInstance.GetDeferral();
        var msg = await MeasureRequestTime();
        ShowToast(msg);
        deferral.Complete();
    }
 
    private async Task MeasureRequestTime()
    {
        string msg;
        try
        {
            var url = ApplicationData.Current.LocalSettings.Values["UrlToVerify"] as string;
            var http = new HttpClient();
            Stopwatch clock = Stopwatch.StartNew();
            var response = await http.GetAsync(new Uri(url));
            response.EnsureSuccessStatusCode();
            var elapsed = clock.ElapsedMilliseconds;
            clock.Stop();
            msg = $"{url} took {elapsed.ToString()} ms";
        }
        catch (Exception ex)
        {
            msg = ex.Message;
        }
        return msg;
}

 

Обратите внимание, как используется LocalSettings в ApplicationData для обмена информацией между WPF приложением и фоновой UWP задачей.

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

Для регистрации фоновой задачи в системе, Вам нужно вызвать Windows 10 API из WPF приложения. Этот API доступен в Windows 10 SDK, и для его использования с .NET необходимо добавить ссылки, объясненные здесь. После того, как Вы получили доступ к Windows 10 API, Вы можете использовать класс BackgroundTaskRegistration для настройки фоновой задачи, как показано в приведенном ниже коде:

 

public void RegisterBackgroundTask(String triggerName)
{
    var current = BackgroundTaskRegistration.AllTasks
        .Where(b => b.Value.Name == triggerName).FirstOrDefault().Value;
 
    if (current is null)
    {
        BackgroundTaskBuilder builder = new BackgroundTaskBuilder();
        builder.Name = triggerName;
        builder.SetTrigger(new MaintenanceTrigger(15, false));
        builder.TaskEntryPoint = "HttpPing.SiteVerifier";
        builder.Register();
        System.Diagnostics.Debug.WriteLine("BGTask registered:" + triggerName);
    }
    else
    {
        System.Diagnostics.Debug.WriteLine("Task already:" + triggerName);
    }
}

 

Для регистрирации фоновой задачи, убедитесь, что задача не была зарегистрирована ранее, а затем используйте BackgroundTaskBuilder для настройки имени и Триггера, в этом случае используется MainteinanceTrigger.

2. Зарегистрируйте Ваше приложение в качестве Share Target

Совместные контракты - это Windows 10 функция, которая позволяет осуществлять обмен информацией между двумя приложениями, отправителем и получателем. Благодаря Desktop Bridge, Вы можете зарегистрировать UWP приложение в качестве общего получателя, а затем интегрировать с Win32 приложением. После регистрации приложения, оно будет отображаться каждый раз, когда пользователь вызывает функцию совместного использования, как показано ниже:

В этом примере, WPF приложение расширяется с добавлением функции совместного использования, где пользователи могут отправлять изображения из других приложений, таких как Photos, Edge, Shell в наше WPF приложение. Microsoft использует проект упаковки, который включает не только WPF, но и UWP приложение, которое позволяет UWP-интерфейсу получать контент из целевого ресурса. Ниже Вы можете увидеть исследователь решений с проектом упаковки, ссылающимся на WPF и UWP проекты.

Пакет должен обозначить цель о совместном использовании (Share Target), включая имя UWP приложения:

При активации, приложение получает информацию о целевом ресурсе из параметра ShareOperation. Ниже приведен пример фрагмента кода:

protected async override void OnNavigatedTo(NavigationEventArgs e)
{
    base.OnNavigatedTo(e);
    operation = (ShareOperation)e.Parameter;
    if (operation.Data.Contains(StandardDataFormats.StorageItems))
    {
        var items = await operation.Data.GetStorageItemsAsync();
        file = items[0] as StorageFile;
        IRandomAccessStreamWithContentType stream = await file.OpenReadAsync();
 
        await this.Dispatcher.RunAsync(CoreDispatcherPriority.Normal, async () =>
        {
            BitmapImage image = new BitmapImage();
            this.img.Source = image;
            await image.SetSourceAsync(stream);
        });
    }
}

 

Теперь каждый раз, когда пользователь делится изображением и выбирает данное приложение, запускается Share UI приложение и затем отображается UWP-интерфейс.

После нажатия кнопки «Поделиться в WPF приложение», UWP вызывает обработчик событий и копирует изображение в папку ApplicationData, и затем запускает Win32 приложение с помощью FullTrustProcessLauncher.

private async void ShareBtn_Click(object sender, RoutedEventArgs e)
{
    await file.CopyAsync(ApplicationData.Current.LocalFolder);
    operation.ReportCompleted();
    await FullTrustProcessLauncher.LaunchFullTrustProcessForCurrentAppAsync();
}

Для использования FullTrustProcessLauncher, применяется Desktop расширение для UWP, это расширение доступно в виде SDK ссылки, которая доступна в диалоговом окне UWP приложения «Add References»:

И, наконец, зарегистрируйте настольное расширение и целевой выполняемый файл в манифесте:

 

<... >

 

3. Добавьте Office взаимодействие из UWP приложения

Одной из ключевых особенностей Desktop Bridge является возможность добавлять исполняемые Win32 файлы в Ваш пакет приложений и запускать их как цельный процесс из UWP приложения. Теперь, с проектом Windows Application Packaging, Вы можете создавать пакеты, содержащие двоичные UWP, так и Win32 файлы.

Дополнительно к диспетчеру процессов, есть расширение App Service, которое поможет Вам установить канал связи между Вашим UWP приложением и Win32 процессом.

В этом примере показан способ добавления Win32 процесса (приложение командной строки) для управления Excel листом с использованием офисного взаимодействия.

Microsoft начинает с UWP приложения, которое использует сетку данных Telerik для отображения некоторых табличных данных, также будет добавлена  кнопка для экспорта одних и тех же данных в Excel, как показано ниже:

Исследователь решений этого примера очень похож на предыдущий пример с тремя проектами в решении: UWP приложение, командная Win32 строка и проект упаковки со ссылкой на оба проекта. Тем не менее, обратите внимание, что в этом случае точкой входа приложения (выделенной жирным шрифтом) является UWP проект:

Как и в предыдущем примере, нужно добавить ссылку на настольное расширение и зарегистрировать полный процесс доверия в манифесте. Но на этот раз, также необходимо зарегистрировать службу приложения в манифесте пакета:

Для открытия канала связи в Win32 процессе, добавьте ссылку на Windows API, как описано здесь:

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

 

Connection = new AppServiceConnection();
connection.AppServiceName = "ExcelInteropService";
connection.PackageFamilyName = Windows.ApplicationModel.Package.Current.Id.FamilyName;
connection.RequestReceived += Connection_RequestReceived;
connection.ServiceClosed += Connection_ServiceClosed;

 

Заключая данную статью

Новые функции, добавленные в проект упаковки в Visual Studio 2017, помогут Вам модернизировать существующие настольные приложения для получения максимального результата от UWP и Win32 в одном пакете. Этот новый проект поможет Вам настроить Ваш пакет с помощью конструктора манифеста, отладить Ваше приложение в контексте Desktop Bridge и, наконец, поможет подготовить пакеты для отправки в Microsoft Store или на другие ресурсы. Для получения дополнительной информации изучите:

 



Posted on 20. July 2017

Вызов WinRT Components из процесса Win32 с помощью Desktop Bridge

В этом посте рассмотрим возможность 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.


  
    CPPSimpleMathWinRT.dll
    
  

Ниже вы увидите простой пример 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, , который позволяет одному или нескольким приложениям быть объявлеными с  FullTrust entrypoint, EntryPoint=”Windows.FullTrustApplication”. Приложения, использующие FullTrust entrypoint, могут вызывать любой API, который им нужен. Обычно это основной исполняемый файл Win32 / .Net. 

Microsoft ссылаются на эти приложения как на приложения FullTrust.

Если у вас нет этой точки входа, приложение работает на более низком уровне доверия, называемом Base Trust, и имеет дополнительные ограничения в изолированной среде под названием AppContainer, что характерно для приложения при создании приложения UWP в Visual Studio. Эти разные уровни доверия приводят к различным требованиям к признакам процесса, и в результате - к другому экземпляру сервера. Эта модель называется ActivateAsActivator или AAA. Ниже приведен пример этой регистрации, и вы заметите, что это то же самое, что и для UWP приложения; нет ничего нового для использования этой инстинктивной модели для доступа к серверу из вашего Win32 кода:

 

  

  
    Microsoft.SDKSamples.Kitchen.exe
    singleInstance
    
  

 

В то время как модель ActivateAsActivator позволяет обмениваться кодами, создание отдельного экземпляра сервера для каждого клиента может быть немного сложнее. Чтобы облегчить процесс, UWP представил концепцию ActivateAsPackage (AAP), которая обеспечивает одинаковое поведение для серверов в пакете. Это отображено в новом атрибуте IdentityType=”activateAsPackage” в элементе .

Однако существует ограничение в модели 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:

  

  
    Microsoft.SDKSamples.Kitchen.exe
    singleInstance
    
  
AAP-регистрация сервера для использования  UWP процессами:

  

  
    Microsoft.SDKSamples.KitchenUWP.exe
    singleInstance
    
  

Образец использует 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 и добавив ссылку на проект прямо в файл проекта, например:

 


  

 

Хотя это добавляет ссылку, вы увидите предупреждение в Visual Studio, поскольку ранее это не поддерживалось. Microsoft продолжает работать с Visual Studio, чтобы улучшать его с каждой новой версией, но пока вы можете игнорировать предупреждение.

Во-вторых, образцы используют UWP JavaScript проект для обработки упаковки приложения. Этот метод отмечен в документе Desktop Bridge Packaging с документацией Visual Studio и работает как разумное решение, до тех пор пока Visual Studio не добавит поддержку. Преимущество этого подхода заключается в том, что вы можете добавить ссылку с вашего компонента WinRT в проект JavaScript, а затем система сборки Visual Studio добавляет соответствующие регистрации для зависимостей пакетов, включая VCLib и .NetNative, а также расширения . Visual Studio не поддерживает добавление регистраций , поэтому вам нужно будет добавить их в манифест вручную.

Сборка на основе метаданных - никаких Proxy/Stub DLL!

Наконец-то, в примере используются приемущества сборки на основе метаданных (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? Дайте нам знать!