Marvin's Blog【程式人生】

Ability will never catch up with the demand for it

23 Nov 2019

AppConsult博文(DesktopBridge相关)阅读笔记 (一)

学习博文https://blogs.msdn.microsoft.com/appconsult/tag/desktop-bridge/来了解UWP Desktop Bridge的Approach。

201610 Desktop Bridge – The bridge between desktop apps and the Universal Windows Platform

Desktop Bridge的前身叫做Project Centennial,可以把非WinRT程序(也就是Win32程序)打包成AppX格式,在Microsoft Store发行。

AppX是新的打包格式,InstallShield、Wix以及Advanced Installer都支持。从Win10 Anniversary Update开始,AppX可以直接点击安装。但是AppX需要一个可信的签名。 AppX的若干好处

  • 可以发布到Microsoft Store上
  • 可以通过脚本在计算机群组中自动分发
  • 支持Mobile Device Management工具,比如Microsoft Intune
  • 可以上传到网站上共享,或者通过USB直接拷贝

个人理解: AppX打包后的应用程序给操作系统提供了一个全新的管理粒度。Win32应用只有用户执行权限控制,应用本身没有权限控制。而AppX则引入了一些应用本身相关的权限控制。

用Desktop Bridge打包的好处:

  • 学习mac,整体打包,牺牲一点硬盘空间,换取操作性。易于安装卸载,整体性强。
  • 好多WinRT的API依赖于Package Identity,只有在打包的应用程序内才能使用。

如果将Win32程序转化为UWP程序,五步走:

  1. 转化(Convert):通过DAC(Desktop Application Converter)将Win32程序重新打包成AppX格式,使其具有Package Identity。
  • 注意:这一招现在已经不能用了。最新的办法是使用VS的Application Packaging Template工程来打包。
  1. 增强(Enhance):在Win32程序之内调用某些WinRT的API,来执行Toast通知,磁贴更新等等操作。
  2. 扩展(Extend):通过WinRT Component来扩展Win32程序,让其可以使用Background Task、App Services、XAML UI部件等等。
  3. 迁移(Migrate):打包两个程序,一个是UWP,另一个是Win32。以UWP为主,Win32作为扩展,以Desktop Extension的方式供UWP调用。
  4. 达成(Reach all):去除Win32部分,剩下完完全全的UWP程序。

通过Desktop Bridge打包的应用程序的执行权限依然很高,需要FullTrust,所以审批起来也会更严格。需要通过https://developer.microsoft.com/en-us/windows/projects/campaigns/desktop-bridge提交,然后等待AppConsult的工作人员联系你。

201610 Desktop Bridge – Enhancing a desktop application with the UWP APIs

本文展示了一个例子:https://github.com/qmatteoq/DesktopBridge/tree/master/3.%20Convert

上述例子在VS2019中无法构建

子啊WinForms中调用WinRT Api的话,需要在项目中引用Windows.winmd(C:\Program Files (x86)\Windows Kits\10\UnionMetadata)。完成这一步之后,就可以调用一部分WinRT的Api(https://msdn.microsoft.com/en-us/windows/uwp/porting/desktop-to-uwp-supported-api)。

201611 Desktop Bridge – Identify the application’s context

在迁徙的过程中可以会遇到一些情况,你的代码既要可以当作Win32程序用,又要当作WinRT程序用。本文介绍了使用GetCurrentPackageFullName()来判断执行上下文,以便在代码中区别对待是Win32还是WinRT。

作者还提供了一个Helper库:https://github.com/qmatteoq/DesktopBridgeHelpers

201611 Desktop Bridge – Expanding a desktop application with a UWP component

UWP应用的生命周期和传统的Win32应用不同。Win32应用而言,用户有完全的决定权,可以决定何时启动应用,何时杀死应用,操作系统只是被动接受通知。对于UWP而言,为了节省资源和能耗,以适配更多的设备,不能让应用肆无忌惮运行并消耗资源。UWP有前台(foreground)和后台(background)的慨念。如果一个UWP应用切入后台,虽然这个应用程序还能驻留在内存,但是它具有的资源会被操作系统回收。

关于上面这一点,更多可以参考Windows team的博文:https://blogs.windows.com/buildingapps/2016/04/28/the-lifecycle-of-a-uwp-app/

UWP的后台,需要通过(幕后任务)Background Task这个慨念来执行。幕后任务跟触发事件挂钩,当一个幕后任务被触发时,能够执行一定的时间,比如最长30秒。

that Windows 10 Anniversary Update引入了一个概念,叫做single background process model,意味着实现幕后任务的代码不需要放置在一个Windows Runtime Component中,而是包含在UWP APP本身的代码中。

为什么传统的Win32应用程序有可能需要用到WinRT的幕后任务呢:

  • 幕后任务是事件驱动的,即使程序关闭,也可以被触发加载。而Win32程序必须保持本身一直运行(比如采用Windows Service的方式实现)。
  • 幕后任务不会跑飞。系统会监控幕后任务的资源使用。
  • 幕后任务的触发事件是系统提供的,Win32程序可能实现不了类似的触发器。

在本文的例子程序中,WinForms App需要引用:

  • The Windows.md file, stored in the path C:\Program Files (x86)\Windows Kits\10\UnionMetadata
  • The System.Windows.Runtime.dll file, stored in the path C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETCore\v4.5.1

例子中的WinRT Component实现了一个幕后任务,并且需要在manifest中申明:

<Extensions>
  <Extension Category="windows.activatableClass.inProcessServer">
    <InProcessServer>
      <Path>CLRHost.dll</Path>
      <ActivatableClass ActivatableClassId="TileBackgroundTask.TileTask" ThreadingModel="both" />
    </InProcessServer>
  </Extension>
</Extensions>

上述申明在UWP应用中并不需要。

例子代码链接https://github.com/qmatteoq/DesktopBridge/tree/master/5.%20Extend,此项目尚需要使用xcopy将pri和winmd文件拷入到PackageLayout目录。

Matteo Pagani的一些Comments:

background tasks are handled by a unique Windows process (backgroundTaskHost.exe), there isn’t a separate process for every task. You can see all the registered tasks in Windows by opening the Windows Settings and go to Privacy -> Background Apps.

the best way would be to include an alias for your app in your converted version of the application: https://docs.microsoft.com/en-us/windows/uwp/porting/desktop-to-uwp-extensions#alias

With this approach, an alias to your main executable will be registered into the system and, no matter where you are going to invoke it (a shortcut, a command prompt, another application, etc.), the converted version of your app will start.

Desktop Bridge – Multiple desktop processes, a single UWP container

你或许注意到了,一个UWP Container可以跑多个进程,它们共享本地存储(比如AppData)。上一篇笔记的例子中,一个UWP Container跑了两个进程,一个是Winforms应用的进程,另一个是幕后任务的进程。

处于同一个UWP Container的进程,它们的注册表都是虚拟,以及共享的。当AppX被删除时,相应注册表的内容也被清空。

本文例子: https://github.com/qmatteoq/DesktopBridge/tree/master/Extras/Container

201612 Desktop Bridge – The Migrate phase: invoking a Win32 process from a UWP app

本篇介绍了Desktop Bridge的Migrate阶段,并介绍了AppService。

从代码上看,AppService是一个WinRT Component,包含一个实现了IBackgroundTask接口的类,以及一个方法Run()来运行这个AppServie。和幕后任务不太相同的是AppService不需要指定Trigger,即可被其他App调用。(或者说,Trigger为其他App的调用)。

AppService的一些相关状况:

  • 使用到AppService的解决方案通常有两个工程,一个UWP APP工程,还有一个WinRT Component工程。
  • UWP App工程将WinRT Component注册成为AppService
  • 用户从Store安装UWP App的时候,也会顺带安装AppService

话锋一转,文章开始介绍separate process background model(分离进程后台模型)和 single process background model(单一进程后台模型)。后者在 Anniversary Update 中引入。

在分离模型中,幕后任务在backgroundTaskHost.exe中运行,这在共享资源时有所不便。在单一进程模型中,Run()方法被挪到了App中(比如App.xaml.cs),有了一个新的名字:OnBackgroundActivated。

接下来作者详细说明了例子:https://github.com/qmatteoq/DesktopBridge/tree/master/6.%20Migrate

其他

Full Trust Capability

xmlns:rescap="http://schemas.microsoft.com/appx/manifest/foundation/windows10/restrictedcapabilities"

<Capabilities>
<Capability Name="internetClient" />
<rescap:Capability Name="runFullTrust" />
</Capabilities>

参考

(本篇完)

comments powered by Disqus