Posted on 20. December 2018

Упаковка .NET Core приложения с помощью Desktop Bridge

Windows Desktop Bridge – это способ упаковки десктопных приложений для отправки в Microsoft Store или загрузки с любого ресурса. Это один из путей создания MSIX пакета. Вкратце: пользуйтесь им, как современным ClickOnce. Это формат упаковки с поддержкой автоматического обновления и пользователи уверены, что он не нанесет вред их системе и не загрязнит реестр.

Ранее Microsoft объявили о первых предварительных .NET Core 3 и Visual Studio 2019 версиях. Эти пробные варианты поддерживают создание графических ПК приложений с помощью .NET Core с использованием WPF и Windows Forms. Можно перенести существующее приложение из .NET Framework в .NET Core 3. Приложение, которое уже переключилось, – это NuGet Package Explorer; его открытый исходный код уже доступен на GitHub и служит отличным примером.

Если у Вас есть приложение, ориентированное на .NET Core 3, то у Вас могут возникнуть вопросы: «Как мне поделиться этим с моими пользователями?», «.NET Core 3 совершенно новый, у моих пользователей этого не будет!» «Мой IT-отдел не будет выпускать .NET Core 3 в течение года!»

Одна из действительно интересных вещей в .NET Core – это то, что он поддерживает полностью автономные приложения. То есть он не имеет внешних зависимостей. Вам не нужно ничего устанавливать, даже сам .NET Core. Вы можете скопировать вывод публикации проекта и передать его кому-нибудь для запуска. Это открывает огромные возможности, так как Вы, как разработчик, можете использовать нужные Вам фреймворки и рабочие версии, не беспокоясь о том, что помешаете другим приложениям, запущенным на компьютере, даже если рабочий вариант уже существует в box.

С полностью автономным приложением Вы сможете использовать Desktop Bridge для упаковки Вашей программы, чтобы пользователи легко могли её установить. На сегодняшний день шаблоны не поддерживают этот нестандартный сценарий, но, настроив должным образом, его можно запустить.

Вначале

Вам понадобится Visual Studio 2017 15.9 или, еще лучше, новый выпуск Visual Studio 2019 Preview. В настройках обязательно выберите рабочую нагрузку UWP для установки инструментов проекта упаковки. Загрузите .NET Core 3 Preview и создайте в нем первое WPF .NET Core приложение.

Подробно

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

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

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

 

  1. Основной проект приложения, пример NetCoreDesktopBridgeApp.csproj.
  2. Проект упаковки, пример NetCoreDesktopBridgeApp.Package.wapproj.

 

Проект приложения

Начнем с основного проекта приложения, .csproj или .vbproj файла. Добавьте win-x86 к первой . Это гарантирует, что восстановление NuGet предоставит ресурсы, специфичные для среды выполнения, и поместит их в project.assets.json файл. Затем вставьте следующее:

 


  
    <_PublishItem Include="@(ResolvedFileToPublish->'%(FullPath)')" TargetPath="%(ResolvedFileToPublish.RelativePath)" OutputGroup="__GetPublishItems">
    <_PublishItem Include="$(ProjectDepsFilePath)" TargetPath="$(ProjectDepsFileName)">
    <_PublishItem Include="$(ProjectRuntimeConfigFilePath)" TargetPath="$(ProjectRuntimeConfigFileName)">
  

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

 

  


  
    WinExe
    netcoreapp3.0
    true

    
    win-x86
  

  
  
    
      <_PublishItem Include="@(ResolvedFileToPublish->'%(FullPath)')" TargetPath="%(ResolvedFileToPublish.RelativePath)" OutputGroup="__GetPublishItems">
    <_PublishItem Include="$(ProjectDepsFilePath)" TargetPath="$(ProjectDepsFileName)">
    <_PublishItem Include="$(ProjectRuntimeConfigFilePath)" TargetPath="$(ProjectRuntimeConfigFileName)">
    
  


Проект упаковки

Далее нужно добавить в (.wapproj) проект упаковки следующее, еще одно свойство:

 CoreClr

в , которая включает DefaultLanguage и EntryPointProjectUniqueName. Так Visual Studio говорит применять .NET Core отладчик. Примечание: чтобы использовать этот параметр, после установки Вам, возможно, нужно будет разгрузить / перезагрузить проект для VS. Если после изменения этого свойства система выдаст странную ошибку отладки, перезапустите VS, загрузите решение, и все должно заработать.

 

Затем найдите элемент. Если его нет, щелкните правой кнопкой мыши на Application node и добавьте ссылку на приложение в Ваш основной проект. Добавьте следующие атрибуты: SkipGetTargetFrameworkProperties = "true" Properties = "RuntimeIdentifier = win-x86; SelfContained = true". Полная ItemGroup должна выглядеть примерно так:

 


  
  

 

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

 



  @(PackageOutputGroups);__GetPublishItems

 

В этом фрагменте измените NetCoreDesktopBridgeApp\NetCoreDesktopBridgeApp.exe, чтобы он соответствовал имени и исполняемому файлу Вашего основного проекта.

Обходное решение VCRedist

В качестве контрольной точки Вам нужно указать зависимость пакета от VCRedist в Package.appxmanifest файле. Добавьте в элемент следующее:

. Когда пользователи установят Ваше приложение, Windows автоматически подтянет эту зависимость из хранилища.

 

Сборка и отладка

С указанными выше компонентами, Вы можете установить проект упаковки в качестве стартапа и выполнить отладку в обычном режиме. Он создаст программу и развернет его в локальном приложении. Выходные данные можно увидеть в bin\AnyCPU\\AppX каталоге Вашего проекта упаковки. Он должен содержать больше файлов, чем в вашем главном приложении, поскольку в нем будет автономная .NET Core среда выполнения.

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

Развертывание приложения

Существует два основных варианта развертывания пакета:

 

  1. Загрузка с помощью AppInstaller файла. Это замена ClickOnce.
  2. Microsoft Store. Пакет может быть отправлен в Store для распространения.

 

Двойная загрузка

Начиная с Windows 10 1803, загруженные приложения могут автоматически обновляться с помощью .appinstaller файла. AppInstaller является альтернативой ClickOnce для большинства сценариев. В документации описывается, как создать этот файл при публикации и поместить его в UNC-путь, общую папку или HTTPS-папку.

Если Вы загружаете контент, то нужно использовать сертификат подписи кода, которому доверяют Ваши пользователи. Для предприятия это может быть документ внутреннего центра сертификации, для общественности он должно быть получен в государственном органе. У DigiCert есть отличное предложение для сертификатов подписи кода, $ 74 / год для обычного и $ 104 / год для EV по специальной ссылке. После получения сертификата Вам необходимо обновить Package.appxmanifest, чтобы использовать его. В данной статье нет информации об автоматической подписи кода, но Вы можете ознакомиться с проектом службы подписи кода здесь.

Microsoft Store

Microsoft Store – отличный способ, чтобы Ваши пользователи узнали о приложении. Он обрабатывает подписывание кода, распространение и обновление. Более подробная информация о том, как подать приложение в Store, здесь и здесь.

 

Источник



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 23. October 2017

Visual Studio 2017 Update 4

Visual Studio 2017 Update 4 упрощает модернизацию Ваших приложений

В прошлом году обновление Windows 10 Anniversary Update добавило поддержку Desktop Bridge для модернизации приложений с помощью универсальной платформы Windows и их распространения в Windows Store и Microsoft Store for Business на всех Windows 10 ПК, включая устройства, которые работают под управлением Windows 10 S.
В то время, первым инструментом разработчика был Desktop App Converter, который преобразовывает Ваш текущий установщик приложений в пакет Windows приложений (файл .appx), который может быть отправлен в Windows Store или развернут по Вашему выбору. С четвертым обновлением для Visual Studio 2017 добавлена отличная поддержка для работы непосредственно в Visual Studio для Ваших настольных Windows приложений (WPF, Winforms, Win32 и другие). С помощью новых инструментов Вы можете создавать, настраивать, развертывать, тестировать и отлаживать Ваши Desktop Bridge приложения во время разработки в VS, просто нажимая F5!
Сегодня мы покажем Вам пошаговый пример работы с новым обновлением. Начнем с Winforms приложения, которое демонстрирует различные элементы управления диаграммой. Приложение было создано несколько лет назад в старой VS версии с .NET 4. Теперь Microsoft хочет выпустить и постепенно модернизировать его в Windows Store.  В этом блог посте мы покажем Вам, как это легко с Update 4 для Visual Studio 2017.

Шаг 1 - Добавьте к решению проект Windows App Packaging 

Прежде чем начать, убедитесь, что Ваш проект настольных приложений загружен в Visual Studio 2017 и создается без ошибок. Затем, на следующем этапе, необходимо упаковать приложение в виде пакета Windows приложений (файл .appx), чтобы Winforms приложение могло использовать все те же функции развертывания Windows 10 приложений, которые доступны для UWP приложений: чистая установка и удаление, безперебойные обновления, распространение в Store и многое другое. Для этого Вам нужно воспользоваться новыми возможностями инструментов в четвертом обновлении Visual Studio 2017. Microsoft добавляет новый проект к решению «Windows Application Packaging Project»:

Теперь нужно указать Ваши минимальные / целевые версии ...

... укажите в проекте упаковки, какой проект должен быть включен в пакет. Для этого щелкните правой кнопкой мыши на узле «Applications» и установите ссылку на Winforms проект.

Важно! Выберите проект «DistributionPackage» в качестве запуска Вашего проекта. Затем, нажмите F5 и посмотрите, как Ваше приложение будет упаковано, развернуто и запущено в качестве Desktop Bridge приложения. Вы можете начать тестирование и отладку в новом контексте выполнения. Если Вы установите проект Winforms в качестве проекта запуска и нажмете F5, Вы все равно можете проверять и отлаживать неупакованную версию Вашего приложения.

Шаг 2 – Настройка приложения для публикации в Windows Store

Итак, Ваше приложение уже работает как Desktop Bridge приложение, и Вы успешно его протестировали и отладили в этой конфигурации. Затем Вам просто нужно приложить завершающие штрихи к пакету, чтобы он хорошо сочетался с Windows 10 Shell (тайлы, символы и другое) и убедиться, что пакет соответствует требованиям публикации Windows Store. Во-первых, нужно заменить визуальные активы по умолчанию, подвязанные к шаблону проекта, на действительные, специфичные для приложения активы. В Visual Studio 2017 это очень легко с помощью Visual Assets Manager в редакторе манифеста пакета:

Чтобы подготовиться к публикации в Windows Store, необходимо создать приложение в Windows Dev Center и зарезервировать имя Вашего приложения, загрузить скриншоты, установить цену, возрастные категории и другое. Если Вы не планируете распространять приложение в Windows Store, Вы можете пропустить этот шаг.

Последнее, что нужно сделать перед публикацией Вашего приложения, - это создать пакеты, которые готовы к развертыванию и совместимы с требованиями Windows Store. Этот пакет может содержать двоичные файлы для разных архитектур, ресурсы для разных локалей, а также символы для двоичных файлов, чтобы в дальнейшем Вы могли проанализировать любые отчеты о сбоях в Dev Center или Mobile Center. Это можно сделать для Desktop Bridge приложений, как и для любого UWP приложения, непосредственно из Visual Studio:

В рамках создания пакетов, также проводятся сертификационные тесты, после которых пакеты отправляются на сертификацию и публикацию в Dev Center. Теперь Вы можете оценить результат Вашей публикации и установить пример приложения на Ваш компьютер из Windows Store, здесь доступен исходный код приложения.

Какие дополнительные преимущества открываются разработчикам?

Помимо распространения и монетизации через Windows Store, Ваше приложение обладает современными возможностями развертывания, встроенными в Windows 10. Вам больше не нужно создавать установщик, обновления являются автоматическими и дифференциальными. Удаление приложения гарантированно будет правильным. Кроме того, так как Ваше приложение теперь находится в Windows 10 App Model, у Вас есть доступ к API и UWP функциям, таким как живые плитки, интеграция Cortana, фоновые задачи и другие. Еще одним важным преимуществом специально для Windows Forms приложений является новая качественная DPI поддержка в .NET 4.7, которая включена в Windows Creators Update (1703). В данном примере, приложение использует эту новую поддержку, следуя шагам, описанным в этой статье.

Более того

Говоря об установщиках, знаете ли Вы, что пакет Вашего приложения также является Вашим установщиком в Windows 10? Пользователи могут просто щелкнуть, чтобы установить его, если он подписан с сертификатом, который доступен для целевого устройства. Это позволяет распространять Ваше модернизированное настольное приложение таким образом, чтобы это соответствовало Вашему сценарию, без необходимости публикации в Windows Store - например, для LOB приложений на предприятии. Здесь Вы можете узнать больше о данной возможности.

Вывод

Получение готового проекта разработки настольных приложений для публикации в Windows Store стало намного легче с четвертым обновлением Visual Studio 2017. После преобразования Вашего Windows приложения в Windows App Package, оно может пользоваться всеми преимуществами Windows 10 и начать использовать новые API и функции Windows 10. Здесь Вы найдете ресурсы для получения дополнительной информации:

Оригинал анонса



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? Дайте нам знать!



Posted on 12. May 2017

Поддержка COM-сервера и OLE-документа для Desktop Bridge

Windows 10 Creators Update добавляет поддержку автономного (OOP) COM и OLE для приложений на Desktop Bridge - так называемого Packaged COM. В прошлом, приложения Win32 создавали COM-расширения, которые могли бы использовать другие приложения. Например, Microsoft Excel раскрывает Excel.Application, поэтому сторонние приложения могут автоматизировать операции в Excel, используя свою богатую объектную модель. Но в первоначальном выпуске Desktop Bridge с Windows 10 Anniversary Update  приложение не может выставлять точки расширения COM, поскольку все записи реестра находятся в его частном улье и публично не отображаются в системе. Packaged COM предоставляет механизм для записей COM и OLE, объявляемых в манифесте,  чтобы они могли использоваться внешними приложениями. Базовая система обрабатывает активацию объектов, чтобы их можно было потреблять клиентами COM - все это еще невыполненные обещания Universal Install Platform (UWP): не оказывать никакого воздействия на установку и удаление.

Как это работает

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

Во время выполнения COM-вызова, то есть вызова CLSIDFromProgID() или CoCreateInstance(), система сначала просматривается в каталоге Packaged COM, и если она не найдена, возвращается обратно в системный реестр. Затем, COM-сервер активируется и запускает ООP из клиентского приложения.

Когда использовать Packaged COM

Packaged COM очень полезен для приложений, которые предоставляют сторонние точки расширения, однако не все приложения нуждаются в этом. Если ваше приложение использует COM только для личного использования, вы можете полагаться на записи COM в частном улье (Registry.dat), чтобы поддержать ваше приложение. Все бинарные файлы в одном и том же пакете имеют доступ к этому реестру, но любые другие приложения в системе не могут видеть их в вашем частном улье. Packaged COM позволяет вам чётко контролировать, какие серверы могут быть опубликованы и использованы сторонними разработчиками.

Ограничения

Поскольку записи Packaged COM хранятся в отдельном каталоге, приложения, которые непосредственно читают реестр (например, вызывая RegOpenKeyEx () или RegEnumKeyEx ()), не будут видеть никаких записей и следовательно - не сработают. В этих сценариях приложениям, которые предоставляют расширения, необходимо будет работать со своими партнерами, чтобы выполнить вызовы COM API или предоставить другой механизм связи между приложениями.

Поддержка распространяется на серверы OOP, что позволяет выполнять два ключевых требования. Во-первых, поддержка сервера OOP означает, что Desktop Bridge может сохранить свою работоспособность. Запустив расширения OOP, диспетчер обновлений может закрыть COM-сервер и обновить все двоичные файлы, потому что в нем нет используемых библиотек DLL, загружаемых другими процессами. Во-вторых, OOP допускает более надежный механизм расширения. Если внутрипроцессный COM-сервер зависает, также зависнет и приложение; для OOP размещенное приложение будет по-прежнему функционировать и сможет решить, как обращаться с неподобающим ООP-сервером.

Мы не поддерживаем все записи регистрации COM и OLE, полный список поддерживаемых нами компонентов можно найти в иерархии элементов манифеста пакета приложения Windows 10 на MSDN: https://docs.microsoft.com/uwp/schemas/appxpackage/uapmanifestschema/root-elements

Рассмотрим внимательнее

Ключами к включению этой функциональности являются новые категории расширений манифеста «windows.comServer» и «windows.comInterface». Расширение «windows.comServer» соответствует типичным регистрационным записям, найденным в CLSID (т.е. HKEY_CLASSES_ROOT \ CLSID \ {MyClsId} ) Для приложения, поддерживающего исполняемые серверы и их классы COM (включая их записи регистрации OLE), суррогатные серверы, классы ProgID и TreatAs. Расширение «windows.comInterface» соответствует типичным регистрационным записям как в HKCR \ Interface \ {MyInterfaceID}, так и в HKCR \ Typelib \ {MyTypelibID}, и поддерживает интерфейсы, ProxyStubs и Typelibs.

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

Пример # 1: Регистрация .exe COM-сервера

В этом первом примере мы упакуем ACDual для Desktop Bridge. ACDual - это пример MFC OLE, который поставляется в более ранних версиях Visual Studio. Данное приложение является .exe COM-сервером, ACDual.exe, с Document CoClass, который реализует интерфейс IDualAClick. Затем он может использоваться пользователем. Ниже предоставлено изображение сервера ACDual и простого клиентского приложения WinForms, которое его использует:

Рис. 1 приложение Client WinForms, автоматизирующее AutoClick COM-сервер

Ссылка Store: https://www.microsoft.com/store/apps/9nm1gvnkhjnf

Ссылка GitHub: https://github.com/Microsoft/DesktopBridgeToUWP-Samples/tree/master/Samples/PackagedComServer

 

Отличие реестра от AppxManifest.xml

Чтобы понять, как работает Packaged COM, важно сравнить типичные записи в реестре с вложенными COM-записями манифеста. Обычно для минимального COM-сервера требуется CLSID с ключом LocalServer32, а также интерфейс, указывающий на ProxyStub для обработки перекрестного процесса маршалинга. ProgIDs и TypeLibs облегчают чтение и программирование. Давайте посмотрим на каждый раздел и сравним, как выглядит системный реестр, по сравнению с фрагментами Packaged COM. Прежде всего, посмотрим на следующие записи ProgID и CLSID, которые регистрируют сервер в системном реестре:

; ProgID registration
[HKEY_CLASSES_ROOT\ACDual.Document]
@="AClick Document"
[HKEY_CLASSES_ROOT\ACDual.Document\CLSID]
@="{4B115281-32F0-11CF-AC85-444553540000}"
[HKEY_CLASSES_ROOT\ACDual.Document\DefaultIcon]
@=”C:\\VCSamples\\MFC\\ole\\acdual\\Release\\ACDual.exe,1”
 
; CLSID registration
[HKEY_CLASSES_ROOT\CLSID\{4B115281-32F0-11CF-AC85-444553540000}]
@="AClick Document"
[HKEY_CLASSES_ROOT\CLSID\{4B115281-32F0-11CF-AC85-444553540000}\InprocHandler32]
@="ole32.dll"
[HKEY_CLASSES_ROOT\CLSID\{4B115281-32F0-11CF-AC85-444553540000}\LocalServer32]
@="\"C:\\VCSamples\\MFC\\ole\\acdual\\Release\\ACDual.exe\""
[HKEY_CLASSES_ROOT\CLSID\{4B115281-32F0-11CF-AC85-444553540000}\ProgID]
@="ACDual.Document"

 

Для сравнения перевод в манифест пакета прост. ProgID и CLSID поддерживаются через расширение windows.comServer, которое должно находиться под элементом приложения вашего приложения вместе со всеми вашими другими расширениями. Что касается ProgID, вы можете иметь несколько регистраций ProgID для вашего сервера. Обратите внимание, что по умолчанию значение ProgID не указано для предоставления дружественного имени, так как эта информация сохраняется с регистрацией CLSID, и одна из целей схемы манифеста заключается в уменьшении дублирования информации. Регистрация CLSID включена через элемент ExeServer с атрибутом Executable, который представляет собой относительный путь к .exe, содержащемуся в пакете. Относительные пути пакетов решают одну общую проблему: декларативно регистрировать COM-серверы: в файле .REG вы не знаете, где находится ваш исполняемый файл. Часто все файлы в пакете помещаются в корень пакета. Элемент регистрации Class находится в элементе ExeServer. Вы можете указать один или несколько классов для ExeServer.

    

    
      
          
      
        
          
          
            
             
                
          
          
          
        
      
 

Следующим шагом будет TypeLib и регистрация интерфейса. В этом примере TypeLib является частью основного исполняемого файла, и интерфейс использует стандартный маршалер (oleaut32.dll) для своего ProxyStub, поэтому регистрация происходит следующим образом:

 

[HKEY_CLASSES_ROOT\Interface\{0BDD0E81-0DD7-11CF-BBA8-444553540000}]
@="IDualAClick"
[HKEY_CLASSES_ROOT\Interface\{0BDD0E81-0DD7-11CF-BBA8-444553540000}\ProxyStubClsid32]
@="{00020424-0000-0000-C000-000000000046}"
[HKEY_CLASSES_ROOT\Interface\{0BDD0E81-0DD7-11CF-BBA8-444553540000}\TypeLib]
@="{4B115284-32F0-11CF-AC85-444553540000}"
"Version"="1.0"
 
 
;TypeLib registration
[HKEY_CLASSES_ROOT\TypeLib\{4B115284-32F0-11CF-AC85-444553540000}]
[HKEY_CLASSES_ROOT\TypeLib\{4B115284-32F0-11CF-AC85-444553540000}\1.0]
@="ACDual"
[HKEY_CLASSES_ROOT\TypeLib\{4B115284-32F0-11CF-AC85-444553540000}\1.0\0]
[HKEY_CLASSES_ROOT\TypeLib\{4B115284-32F0-11CF-AC85-444553540000}\1.0\0\win32]
@=" C:\\VCSamples\\MFC\\ole\\acdual\\Release\\AutoClik.TLB"
[HKEY_CLASSES_ROOT\TypeLib\{4B115284-32F0-11CF-AC85-444553540000}\1.0\FLAGS]
@="0"
[HKEY_CLASSES_ROOT\TypeLib\{4B115284-32F0-11CF-AC85-444553540000}\1.0\HELPDIR]
@=""

 

При переводе этого в манифест пакета расширение windows.comInterface поддерживает одну или несколько регистраций TypeLib, ProxyStub и интерфейса. Как правило, он помещается в элемент «Приложение», поэтому для удобства чтения его легче связать с регистрацией классов, но он также может находиться в элементе «Пакет». Также обратите внимание, что нет необходимости запоминать CLSID универсального маршалера (ключ, где ProxyStubClsid32 = {00020424-0000-0000-C000-000000000046}). Это просто флаг: UseUniversalMarshaler = "true".

 

         
         
          
          
          
          
            
          
 
          
          
            
              
            
          
        
      
    
    
  
  

 

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

Пример # 2: поддержка OLE

В следующем примере мы упакуем существующий сервер документов OLE, чтобы продемонстрировать возможности Desktop Bridge и Packaged COM. Пример, который мы будем использовать, - это пример приложения MFC Scribble, который предоставляет вставляемый тип документа Scribb Document. Scribble - простой сервер, который позволяет OLE-контейнеру, например WordPad, вставлять документ Scribb.

Рис. 2. WordPad, на котором размещен встроенный Scribb Document

Ссылка Store: https://www.microsoft.com/store/apps/9n4xcm905zkj

Ссылка GitHub: https://github.com/Microsoft/DesktopBridgeToUWP-Samples/tree/master/Samples/PackagedOleDocument

 

Отличие реестра от AppxManifest.xml

Существует много ключей для указания различных атрибутов OLE. Опять же, магия здесь заключается в том, что платформа была обновлена для работы с Packaged COM, и все, что вам нужно сделать, это перевести эти ключи в ваш манифест. В этом примере записи для Scribble включают ProgID, его ассоциации типов файлов и CLSID с записями.

 

;SCRIBBLE.REG
;
;FileType Association using older DDEExec command to launch the app
[HKEY_CLASSES_ROOT\.SCB]
@=”Scribble.Document”
[HKEY_CLASSES_ROOT\Scribble.Document\shell\open\command]
@=”SCRIBBLE.EXE %1”
 
 
;ProgId
[HKEY_CLASSES_ROOT\Scribble.Document]
@= Scribb Document
[HKEY_CLASSES_ROOT\Scribble.Document\Insertable]
@=””
[HKEY_CLASSES_ROOT\Scribble.Document\CLSID]
@= “{7559FD90-9B93-11CE-B0F0-00AA006C28B3}}”
 
 
;ClsId with OLE entries
[HKEY_CLASSES_ROOT\CLSID\{7559FD90-9B93-11CE-B0F0-00AA006C28B3}]
@="Scribb Document"
[HKEY_CLASSES_ROOT\CLSID\{7559FD90-9B93-11CE-B0F0-00AA006C28B3}\AuxUserType]
[HKEY_CLASSES_ROOT\CLSID\{7559FD90-9B93-11CE-B0F0-00AA006C28B3}\AuxUserType\2]
@="Scribb"
[HKEY_CLASSES_ROOT\CLSID\{7559FD90-9B93-11CE-B0F0-00AA006C28B3}\AuxUserType\3]
@="Scribble"
[HKEY_CLASSES_ROOT\CLSID\{7559FD90-9B93-11CE-B0F0-00AA006C28B3}\DefaultIcon]
@="\"C:\\VC2015Samples\\scribble\\Release\\Scribble.exe\",1"
[HKEY_CLASSES_ROOT\CLSID\{7559FD90-9B93-11CE-B0F0-00AA006C28B3}\InprocHandler32]
@="ole32.dll"
[HKEY_CLASSES_ROOT\CLSID\{7559FD90-9B93-11CE-B0F0-00AA006C28B3}\Insertable]
@=""
[HKEY_CLASSES_ROOT\CLSID\{7559FD90-9B93-11CE-B0F0-00AA006C28B3}\LocalServer32]
@="\"C:\\VC2015Samples\\scribble\\Release\\Scribble.exe\""
[HKEY_CLASSES_ROOT\CLSID\{7559FD90-9B93-11CE-B0F0-00AA006C28B3}\MiscStatus]
@="32"
[HKEY_CLASSES_ROOT\CLSID\{7559FD90-9B93-11CE-B0F0-00AA006C28B3}\ProgID]
@="Scribble.Document"
[HKEY_CLASSES_ROOT\CLSID\{7559FD90-9B93-11CE-B0F0-00AA006C28B3}\Verb]
[HKEY_CLASSES_ROOT\CLSID\{7559FD90-9B93-11CE-B0F0-00AA006C28B3}\Verb\0]
@="&Edit,0,2"
[HKEY_CLASSES_ROOT\CLSID\{7559FD90-9B93-11CE-B0F0-00AA006C28B3}\Verb\1]
@="&Open,0,2"

 

 

Прежде всего, стоит обсудить ассоциацию типов файлов. Это расширение, которое поддерживалось в первой версии расширений Desktop Bridge. Обратите внимание, что указание здесь ассоциации типов файлов автоматически добавляет поддержку открытой командной  оболочки.

Далее, подробнее расмотрим записи ProgID и CLSID. В данном случае простой пример имеет только ProgID, а не VersionIndependentProgID.

Большая часть волнений в этом примере находится под CLSID, где находятся все ключи OLE. Ключи реестра обычно сопоставляются с атрибутами класса, например:

 

Вставляемый ключ под ProgID или CLSID, сопоставляется с атрибутом InsertableObject = "true"

Если ключ InprocHandler32 является Ole32.dll, используйте атрибут EnableOleDefaultHandler = "true"

AuxUserType\ 2 отображается в ShortDisplayName

AuxUserType\ 3 сопоставляется с приложением DisplayName

 

В тех случаях, когда в ключе было много значений, например, глаголов OLE, мы разделяем их на отдельные атрибуты. Ниже показан полный манифест:

 

  
 
  
    
    
      
        
          
            .scb
          
        
      
 
      
        
          
            
            
              
              
              
                
                
              
            
          
          
          
          
        
      
    
  

 

Дополнительная поддержка

 

В двух приведенных выше примерах рассмотрены наиболее распространенные случаи использования COM-сервера и поддержки документов OLE. Packaged COM также поддерживает дополнительные серверы, такие как Surrogates и TreatAs классы. Более подробную информацию вы можете найти в иерархии элементов манифеста пакета Windows 10 приложений на MSDN: https://docs.microsoft.com/uwp/schemas/appxpackage/uapmanifestschema/root-elements

 

Заключение

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

Для получения дополнительной информации о Desktop Bridge посетите Windows Dev Center.

Готовы ли вы отправить свое приложение в Windows Store? Дайте знать!



Posted on 3. April 2017

Desktop Bridge: Creators Update

В Creators Update добавлены новые функции для разработчиков приложений и конечных пользователей. Новые возможности помогут разработчиками выпустить приложения для пользователей с богатым опытом.


Перенос пользователей и данных

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

В результате Creators Update будет обеспечивать плавный переход вместе с некоторыми рекомендациями для разработчиков приложений.

Подробный пост по этой теме с образцами кода см. в этой пошаговой инструкции.


Переход пользователя: контакты панели задач и иконки на начальном экране

Многие пользователи обычно прикрепляют свои любимые или наиболее часто используемые приложения к панели задач или меню «Пуск», чтобы быстро получать доступ к приложениям.

С помощью Creators Update разработчики приложений могут повторно перенаправить значки панели задач и иконки начальной панели на версии приложений из Windows Store.


Пользовательский переход: ассоциации типов файлов и обработчики протоколов

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


Перенос данных

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

Пользователям понравится, что они смогут возобновить работу с того места, где остановились.


Переход пользователя: удаление предыдущего настольного приложения

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

Помните, что пользователь может отказаться от удаления предыдущего настольного приложения, поэтому предыдущая и сохраненная версия приложения могут работать вместе. Разработчик приложения должен решить, следует ли блокировать запуск версии Windows Store-приложения до тех пор, пока не будет удалено предыдущее настольное приложение.


Проводник Windows Explorer: предварительный просмотр, эскизы, подробные свойства и группировка по типу

Другой акцент в выпуске Creators Update - удовлетворенность пользователей.

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


Обработчик предварительного просмотра

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

 

Пример XML:


   
      
         
            .bar
         
         
      
   

Обработчик эскизов

В проводнике Windows Explorer эскизы могут предоставляться только для чтения внутри файлов, когда для просмотра установлены иконки среднего размера или выше.

Пример XML:

 

 
   
       
          
            .bar
          
          
       
   
  

 

 

Обработчик свойств

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

 

Пример XML:


   
      
         
            .bar
         
         
      
   

 

Группировка файлов по их «типу»

Разработчики могут указать, какими являются «типы» их файлов, которые позволят конечным пользователям группировать свои файлы по «типу» в Windows Explorer.

 

Пример XML:


   
      
         .m4a
         .mta
      
      
         
         
         
      
   

 

Поддержка установки пользовательских шрифтов приложениями

Приложения Microsoft Windows Store могут совместно использовать свои пользовательские шрифты в других приложениях Windows. Это делается путем внесения нескольких простых изменений в манифест приложения.

Пример XML:


   
      
         
         
      
   

Общедоступная внепроцессная поддержка COM-сервера, также известная как Packaged COM

Теперь разработчики могут добавить поддержку внепроцессных расширений COM и OLE для хранения версий магазина настольных приложений. Эта технология называется Packaged COM. Исторически настольные приложения создавали COM-расширения, которые могли использовать другие приложения. Тем не менее, в выпуске Windows 10 Anniversary Update Desktop Bridge приложение не может выставлять свои точки расширения COM, поскольку все записи реестра находятся в его частном хранилище и не отображаются публично в системе. Packaged COM предоставляет механизм для записей COM и OLE, объявляемых в манифесте, в то время как базовая подсистема обрабатывает активацию объектов, сохраняя при этом беспроигрышную установку.

 

Правила брандмауэра

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

Windows Security Alert пытается обучить пользователя, но это является еще одним решением, которое пользователь должен сделать, прежде чем он сможет использовать свое приложение.

 

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

С помощью Creators Update разработчики могут заранее зарегистрироваться для правил брандмауэра, поэтому пользователям не нужно делать выбор в пользу брандмауэра до запуска своих приложений (в том числе после последующих обновлений приложений).

 

Пример XML:


   
      
         
         
         
         
         
      
   

 

Другие важные функции

 

  • Приложения могут быть предварительно установлены
  • Поддержка интерфейса прикладного программирования для обмена сообщениями (MAPI)
  • Windows App Certification Kit теперь включает тестовые примеры для приложений Desktop Bridge
  • Использование флага URL позволяет приложениям напрямую открывать файлы по URL-адресу вместо загрузки локализованной в кеш-версии файла