December 8, 2016 2:00 pm

Conversion options for bringing your existing desktop app to the Universal Windows Platform using the Desktop Bridge

By / Principal Program Manager Lead

With this summer’s release of the Windows 10 Anniversary update and the recent announcement of the Store supporting apps built with the Desktop Bridge technology, we are receiving much interest from many customers wanting to participate. Many developers are seeing the value of the new Windows 10 app packaging technology that enables your app to cleanly install, uninstall and update, as well as get full access to UWP APIs including Live Tiles, Cortana, notifications and more.

However, the conversion process can be intimidating if you are not familiar with your application’s footprint on the system and the technology it uses. This article is intended to educate you on the options for converting your app’s installation into a Windows app package.


Before we begin to list the options and their various pros and cons, it helps to understand a little about what makes up a Windows app package and how an existing application runs under the Desktop Bridge environment. In the context of the Desktop Bridge, the key parts of an app package, also known as a “.appx” file, has the following:

  • Application files – these are the files your app requires to execute and are usually placed in the root of the package. Typically these are the same files that are installed in the application’s folder under “C:\Program Files” or “C:\Program Files (x86).” In the Universal Windows Platform (UWP), package is placed in an app specific directory under “C:\Program Files\WindowsApps” and are secured to prevent tampering.
  • AppManifest.xml – this file is used by the Windows Store to validate the package contents and identity of the publisher, and it is used by the deployment pipeline to install the application. The purpose of the manifest is to make everything about the installation of a package declarative and thus handled by the system. A key pillar is that no user code is executed at deployment time.
  • Registry.dat – If the application writes to the registry at install time, or the app expects certain registry keys to be set when it starts, this information must be stored in a local application hive. At runtime, this hive is mounted and merged with the system registry so the application sees a merged view. The isolation provided by this model allows for no-impact install and uninstall guarantees provided by the UWP packaging model for apps in the Windows Store.
  • Virtual File System, VFS (optional) – If the application places files in other locations outside its typical product folder, i.e, c:\windows\system32, these files should be placed under the VFS folder. At runtime, the VFS is mounted and merged with the actual file system on disk so the application is presented with a merged view. The isolation provided by this model allows for no-impact install and uninstall guarantees provided by the UWP packaging model for apps in the Windows Store.

After you understand the essential parts that are required for a UWP package, the next step that will influence the conversion is understanding how the application impacts the system – what files are installed where, and what registry entries does the application installer write. Depending on how much a developer knows about their application installer, they can make the decision on the best approach.

Don’t know what your setup package does?

Desktop App Converter

The Desktop App Converter (DAC) is the first option most developers are exposed to, as it requires very little knowledge of the application’s installer. The DAC leverages an isolated environment to install the application. While the install is happening, the isolated environment captures all file system and registry access within that environment and saves the deltas to disk.

The DAC then processes the deltas, filtering out changes made by the OS itself (the isolated environment is similar to a light weight VM running the OS and so there are services, filesystem and registry access happening while the installer is running), and locates your application via shortcuts registered in that environment by the installer. The DAC saves the installer-specific changes, creates the manifest file and sample image assets, and builds the UWP package if specified.

The benefits of this approach are:

  • Straightforward if you know your installer’s silent or unattended setup flags.
  • The DAC can be used to create an initial package, and the output (the PackageFiles folder) can be manually updated with new binaries and rebuilt when there are updates to the application. There is no need to re-run the DAC unless there are significant changes to the installer.

The caveats are:

  • First-time acquisition and setup of the DAC and its base image can take some time.
  • Requires the developer to be familiar with their installer, at least enough to know if it supports a silent or unattended mode. Some installers are not very clear on how to do this and can require a lot of trial and error to figure this out, which is beyond the scope of this article.
  • If the installer hangs, it can be a challenge to get the installer log files for debugging.
  • The file and registry filtering takes a conservative approach to remove system activity because installers can have a broad impact to the system. This approach was taken to ensure the greatest level of compatibility. Developers should review the virtual file system and registry and remove entries that are not associated with their application.

The Desktop App Converter itself can be downloaded from the Windows Store. For more information, please check out the documentation on the Windows Dev Center.

XCopy Deployment?

Manual Packaging

If an application setup is very simple and does not require registry entries nor copying files to protected locations, then a manual packaging option is the most straightforward.  This solution is common for single executable tools or “xcopy” deployments. Typically, all that is required is to place the application files in a folder, and to create an AppManifest.xml with the proper fields updated to identify the publisher and the app executable. Step-by-step instructions for manual packaging can be found on the Windows Dev Center and a sample can be found on GitHub.

Need to support both MSI and Windows 10?

Install technology partners with .appx packaging support

We’ve been working with our partners that build setup technologies to add support for directly building Windows app packages (.appx file) with their tools. These tools will create the app manifest and produce the app package as part of their build process. The key benefit these solutions provide is the ability to maintain one installer code base that will produce an MSI installer typically used in older versions of Windows (e.g. Windows 7), as well as build a no-impact install package for Windows 10 (i.e., .appx file for Windows 10). More information can be found at:

Additionally, Embarcadero has announced support for the Desktop Bridge in RAD Studio, which lets you directly output a Windows app package through the build process.

In summary, the best option depends on how complex the application is and much a developer knows about their existing installation methodology. Whether you have an installer with unknown setup technology, a simple xcopy install, or an application that already has existing assets in a given installer technology, there are approaches to meet your needs.

For more information on the Desktop Bridge, please visit the Windows Dev Center.

Ready to submit your app to the Windows Store? Let us know!

Updated December 19, 2016 11:08 am

Join the conversation

  1. converting the desktop app is the easier half of the story. To get in the store there are a lot of changes required to drop the old licensing code and use the store winRT stuff. It took me a long time to get my win32 head round these things, and here is the summary FYI

  2. From this text not clear:
    1) How to handle ClickOnce apps
    2) How system wide file associations are handled if all registry settings are stored in a local application hive

  3. What I can’t figure out is how to create my own registry.dat file manually and get it to actually merge it. I only need these to tell windows to use IE 11 in my app instead of the default IE 6 but there’s no documentation on how to generate this from a .reg file or something similar.

    Please help!

    • James – its generally easier if you run your installer through the converter, and then analyze/modify the Registry.dat that it produces by loading the hive through RegEdit. However, you can author a .REG file that matches the registry key patterns used by virtual registry system of the Desktop Bridge. Exporting an existing Registry.dat will give you a good idea of what this looks like. In the example below, HKLM\MyApp is just the placeholder for the subkeys that will be mapped at runtime onto the virtual registry. Replace MyApp with your app name (or any temporary name):

      Windows Registry Editor Version 5.00

      You can then import the .REG file and then export the HKLM\MyApp subkey as a registry hive with the filename Registry.dat. Note that relative paths must use the Packaged VFS location tokens documented here:

      Hope that helps,