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-адресу вместо загрузки локализованной в кеш-версии файла