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

KENNETH

7년 ago

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.

Background

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 FilesWindowsApps” and are secured to prevent tampering.
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.
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:windowssystem32, 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!

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