The Desktop Bridge is a technology introduced last year with Windows 10 Anniversary Update, which allows to take existing desktop applications and bring them to the Universal Windows Platform world. In this session, you're going to learn how the Desktop Bridge works, how to convert an existing desktop application and to add new Windows 10 features, by taking advantage of the new tools introduced in Visual Studio 2017 and Windows 10 Creators Update. At the end of the journey, you will have an application which offers a cleaner and smoother installation experience; that has an identity, so it can leverage new Windows 10 features like Windows Hello and Cortana; that you'll be able to deploy through existing channels like the web, Intune or SSCM, but also with new ones like the Windows Store and Windows Store for Business, which will allow you to reach also Windows 10 S users.

2. Agenda 1. Desktop Bridge overview
2. The conversion process
3. Enhancing a packaged app
4. Expanding a packaged app
5. Migrating a packaged app
6. Reach all the devices with UWP

3. Classic desktop applications
• Based on the Windows APIs (Win32) included in Windows
• They are available only in the full edition of Windows for PC and tablets
• They can be developed with multiple technologies and platforms, including
non-Microsoft ones:
o Windows Forms
o WPF
o C++
o Java
o Delphi
o And many more…

4. User experience challenges
today
Getting the right software
Finding the right, trusted installer
Chain-installers (adware)
Staying up-to-date

5. Software vendor challenges
today
Maintaining installer tech
Providing auto-updates
“DLL Hell”
Modernization
Trustworthy distribution
Monetization/licensing

6. Universal Windows Platform

7. Modern deployment technology
• Streamlined developer experience
o No more setup authoring
o Only trusted apps are able to install
o Optimized updates/downloads
• Great user experience
o No elevation/user account control
o Always up-to-date
o Clean uninstallation, minimal system impact
• Ready for the enterprise
o Distribute through sideloading, MDM or
Windows Store for Business

9. A modern packaging system
9
• The Win32 process runs in an isolated
environment, but not in a sandbox like
UWP apps
• Special access to the registry:
o Write operations are stored into a binary
file
o Reading operations are made against a
merge of the system registry and the
binary file
• The AppData folder is mapped with the
same folder used by UWP apps for
local storage, which is isolated

10. The manifest file
A XML file that describes the features of the application, like:
• The entry point
• The identity of the application (name, publisher, CPU architecture,
etc.)
• The capabilities
• The extensions (both special Desktop Bridge and UWP extensions)
• The visual layout of the default assets (tile, store logo, taskbar icon,
etc.)
It’s a declarative and easier model to handle compared to a
regular desktop application

11. File system redirection
• Converted apps are installed in C:Program FilesWindowsApps:
C:Program FilesWindowsAppsMicrosoft.DesktopAppConverter_8wekyb3d8bbwe
• App data is redirected to C:Users<username>AppDataLocalPackages
C:Users<username>AppDataLocalPackagesMicrosoft.DesktopAppConverter_
8wekyb3d8bbweLocalCache

12. The Virtual File System
12
• To solve the “DLL hell” problem, every converted app has a special folder
called VFS, which maps all the system folders (like Program Files, Windows,
System32, etc.)
• When a converted app is running, it will look for 3rd party dependencies in the
VFS folder and not in the system folders
• This way, the package deployment can’t overwrite existing DLLs or
dependencies used by other apps

13. The requirements
13
• A converted application always runs in the user context and can’t elevate
itself as admin
• Your app can’t install a kernel-mode driver or a Windows service
• Your app can’t modify the HKEY_LOCAL_MACHINE (HKLM) registry hive
(since it’s outside the user’s scope)
• Your app can’t write data in the installation folder
• Due to file system redirection and registry virtualization, your app can’t
write in AppData or in the registry with the goal of sharing data with
another app

14. Special extensions
14
Thanks to a set of special manifest extensions, you can still implement most of
the typical features of a desktop app, but in a better and simpler way:
• Startup tasks
• Execution aliases
• Protocol association
• Files and File Explorer integration
• Files preview integration in File Explorer (for example, thumbnails)
• Firewall rules
• Expose COM objects to other applications

15. Demo: The deployment
experience of a converted
desktop application

17. Multiple options to convert a desktop application
17
• Desktop App Converter from Microsoft starting from an installer or a self-
executable application
• Packaging with Visual Studio 2017
• 3rd party tools to create installers like:
o InstallShield
o Wix
o Advanced Installer
o RAD Studio for Delphi
o InstallAware

18. Desktop App Converter and installers
18
• The Desktop App Converter is a command line tool based on a set of
PowerShell scripts, which leverages the Container feature added in the
Anniversary Update
• It’s available from the Store: https://aka.ms/converter
• It requires a base image that matches your current Windows build, that can
be downloaded from https://aka.ms/converterimages
• You need the Windows 10 SDK installed:
https://go.microsoft.com/fwlink/?linkid=821375

19. Sample DAC command
DesktopAppConverter
-Installer "FlightTracker.msi"
-Destination "C:FlightTracker-AppX"
-PackageName "FlightTracker"
-Publisher "CN=AppConsult"
-Version "1.0.0.0"
-MakeAppx -Sign -Verbose

20. Installer requirements
• If it’s a MSI installer, DAC is able to handle it automatically
• If it’s made with another technology, it must support silent installation and you
need to specify the parameter to trigger it using
-InstallerArguments
DesktopAppConverter
-Installer "FlightTracker-Setup.exe"
-InstallerArguments "/S"
-Destination "C:FlightTracker-AppX"
-PackageName "FlightTracker"
-Publisher "CN=AppConsult"
-Version "1.0.0.0"
-MakeAppx -Sign -Verbose

21. Dealing with the CPU architecture
• By default, if the app isn’t compiled for a specific CPU architecture, the DAC will
generate a x64 package
• If you don’t need to address such a big memory space, it’s better to generate a x86
package (or even better, both) to reach a broader range of devices
DesktopAppConverter
-Installer "FlightTracker.msi"
-PackageArch "x86"
-Destination "C:FlightTracker-AppX"
-PackageName "FlightTracker"
-Publisher "CN=AppConsult"
-Version "1.0.0.0"
-MakeAppx -Sign -Verbose

22. What you get as output?
A folder with the app package version of your desktop app
• The app manifest
• Virtual file system
• Binary registry file
• Assets
• Resources for Windows 10 scaling support

24. DAC and manual conversion
• The Desktop App Converter can convert also a standalone application stored
in a folder (executable with its dependencies)
• In this case, the Base Image and the Windows Container feature aren’t
required
• The output is the same as when you use the DAC with a traditional installer,
except for the binary registry file and the virtual file system folder

25. Sample manual DAC command
DesktopAppConverter
-Installer "C:FlightTracker"
-Destination "C:FlightTracker-AppX"
-AppExecutable "FlightTracker.exe"
-PackageName "FlightTracker"
-Publisher "CN=AppConsult"
-Version "1.0.0.0"
-MakeAppx -Sign -Verbose

26. Demo: Desktop App
Converter with a MSI installer

28. Keep a converted project up-to-date
• Typically, the Desktop App Converter is executed just once and it’s the
starting point of the process
• You leverage the output folder and reiterate on it every time you need to
release a new update with some changes, like:
o An updated executable
o One or multiples updated or added DLLs
o One or multiples updated or added images or assets
o New extensions declared in the manifest
• Exception: if you have updated the installer to add new registry keys, 3rd
party dependencies, expose COM objects, etc. you need to run DAC again to
capture all the changes

29. MakeAppX
• MakeAppX is a command line tool included in the Windows 10 SDK that can
generate an app package starting from the output of the DAC
• With the –MakeAppX parameter, the DAC can generate the package
automatically as output of the process
• You can manually generate the package starting from the output folder of
the DAC every time you make some changes
makeappx pack –d "PackageFiles" –p "MyApp.appx" -l

30. SignTool
• If you want to deploy your app manually or in an enterprise environment, the
app must be signed with a trusted certificate
• It can either be a certificate purchase from a certification authority or a self-
generated certificated trusted by all the devices in your company
• If you want to publish the app on the Windows Store or Windows Store for
Business, you don’t need to sign it
• For testing purposes, you can use the –Sign parameter with the DAC to
generate a testing certificate and an already signed app package
• If you have manually generated the package, you can use a command line
tool called SignTool included in the Windows 10 SDK to sign the AppX

31. Verify the package
• If you are on the Anniversary Update, don’t use the Windows App
Certification Kit (WACK) to certify a converted app, since it doesn’t support
them
• If you are on the Creators Update and you have installed the matching SDK,
WACK properly support testing and identifying potential issues in a
converted desktop app

32. Demo: The WACK report

33. Other conversion options
• If you have already an installer for your application created with any of these
tools, you can export an app package directly without using the Desktop App
Converter:
oInstallShield
oWix
oAdvanced Installer
oRAD Studio
oInstallAware

34. Demo: Exporting an app
package using Advanced
Installer by Caphyion

35. Migrate at your own pace
app

37. Enhance
• You can start to leverage some
specific Windows 10 features
• New generation’s UWP APIs to
perform tasks like sending
notifications, updating the live tile or
leverage speech services.
• Keep customers engaged and prompt
them to return to the app thanks to
the new features

38. Supported UWP APIs
• Converted desktop apps can use a wide range of Universal Windows Platform
(UWP) APIs, even if they have not fully transitioned to a UWP app
• Some UWP APIs available to full desktop applications are not supported for
converted apps. If your desktop application used UWP APIs before conversion, you
should verify those APIs are still supported.
• Supported API’s
o You can view APIs newly supported in converted apps or APIs supported in both
converted apps and desktop applications at
https://docs.microsoft.com/en-us/windows/uwp/porting/desktop-to-uwp-supported-
api#new

39. Welcome Visual Studio 2017!
You can add to your existing desktop solution a JavaScript project which will help
you to:
• Generate the app packages
• Edit the manifest using the visual editor
• Generate assets for all the supported Windows scaling factors
Desktop Bridge Debugging Project: a Visual Studio extension to launch and
debug a desktop as converted
https://aka.ms/bridgedebugging

40. Desktop Bridge Helpers
• Goal: keep the same code base both for the converted and the native app
• Open source library based on a C++ method exposed by the Windows kernel
which checks if the app has an identity
• It can detect if the app is running as converted or as native
https://aka.ms/bridgehelpers
DesktopBridge.Helpers bridgeHelpers = new DesktopBridge.Helpers();
if (bridgeHelpers.IsRunningAsUwp())
{
//show a toast notification
}

41. Demo: Enhancing a Windows
Forms app to display a toast
notification

42. Expand

43. Demo: Expanding a Windows
Forms app to use a
background task

44. Migrate

45. Demo: a UWP app which
invokes a Win32 process on
desktop

46. Reach all

47. Demo: moving all your code
to UWP