Using the Desktop App Convertor to create a Windows app package

This week something completely different compared to the last few weeks, maybe even months. This week I’m going to create some awareness for the Desktop App Converter (DAC). DAC is a tool that can be used to bring desktop apps to the Universal Windows Platform (UWP) by using the Desktop Bridge. In this post I’ll start with a short introduction about the Desktop Bridge, followed by an introduction and the usage of DAC. I’ll end this post by providing some deployment considerations.

Desktop Bridge

Lets start with a short introduction about the Desktop Bridge.


The Desktop Bridge, also known as the Desktop to UWP bridge, is the infrastructure that is built into the platform that lets the administrator distribute Windows Forms, WPF, or Win32 desktop app or game efficiently by using a modern Windows app package.
This package gives the app an identity and with that identity, the desktop app has access to Windows Universal Platform (UWP) APIs. These UWP APIs can be used to light up modern and engaging experiences such as live tiles and notifications. Use simple conditional compilation and runtime checks to run UWP code only when the app runs on Windows 10. Aside from the code that is used to light up Windows 10 experiences, the app remains unchanged and the administrator can continue to distribute it to the existing Windows 7, Windows Vista, or Windows XP user base. On Windows 10, the app continues to run in full-trust user mode just like it’s doing today.

Desktop App Convertor

There are multiple methods available to create Windows app packages, from manual packaging (MakeAppx.exe) until using Visual Studio or third-party tooling. All of these are out of scope for this post. IIn this post ’m going to specifically look at using DAC.


DAC can be used to bring desktop apps to the UWP. This includes Win32 apps and apps that are created by using .NET 4.6.1. While the term “Converter” appears in the name of this tool, it doesn’t actually convert the app. The app remains unchanged. However, this tool generates a Windows app package with a package identity and the ability to call a vast range of WinRT APIs. The converter runs the desktop installer in an isolated Windows environment by using a clean base image provided as part of the converter download. It captures any registry and file system I/O made by the desktop installer and packages it as part of the output. For an overview of the workflow, have a look the picture below.


DAC can be very convenient in cases where the app makes lots of system modifications, or if there are any uncertainties about what the installer does. DAC also does a few extra things. Here are a few of them.

  • Automatically register preview handlers, thumbnail handlers, property handlers, firewall rules, URL flags;
  • Automatically register file type mappings that enable users to group files in File Explorer;
  • Register public COM servers;
  • Automatically sign the package so that it can be easily tested;
  • Validate the app against Desktop Bridge and Windows Store requirements.


The goal of this post is to create a Windows app package by using DAC. However, before using DAC, make sure that the system meets the following requirements.

Setup environment

When the system meets the requirements, lets start with setting up the environment. To use DAC for packaging an app that uses an installer, use the following steps to install and set up DAC.

1 Download and install the Desktop App Convertor app;
2 Download the Desktop App Convertor base image that matches the current operating system (in my case I downloaded BaseImage-15063.wim to C:\Temp);
3 Right-click the Desktop App Convertor app and select Run as administrator to start the DesktopAppConvertor console window;
4 In the DesktopAppConvertor console window, set the PowerShell execution policy by using Set-ExecutionPolicy ByPass;

In the DesktopAppConvertor console window, set up the convertor by using DesktopAppConvertor.exe –Setup –BaseImage .C:\Temp\BaseImage-15063.wim –verbose

Note: Make sure to adjust the location and name of the base image when using a different location and/or version;

6 If needed, restart the computer.

Create Windows app package

After setting up the environment, lets start with converting an app. Well, as mentioned before, it’s not actually converting an app, it’s creating a Windows app package. That being said, to use DAC for creating a Windows app package that has a setup executable file, use the following steps.

1 Get the content available locally of the installer that must be converted (in my case I used KeePass-1.33-Setup.exe and placed it in C:\Temp);
2 Right-click the Desktop App Convertor app and select Run as administrator to start the DesktopAppConvertor console window;

In the DesktopAppConvertor console window, start the conversion by using DesktopAppConverter.exe -Installer C:\Temp\KeePass-1.33-Setup.exe -InstallerArguments “/SILENT” -Destination C:\Temp -PackageName “MyKeePass” -Publisher “CN=PTCLOUD” -Version –MakeAppx –Sign –Verbose -Verify

Note: Make sure to adjust the parameters to reflect the information of the app and its location. Also, make sure to run a silent installation, as DAC needs to run the installer in unattended mode.

The parameters are used for the following purpose:

  • Installer: The path to the installer of the application;
  • InstallerArguments: The arguments to run the installer silently;.
  • Destination: The destination for the converter’s appx output;
  • PackageName: The name of the Windows app package;
  • Publisher: The publisher of the Windows app package;
  • Version: The version of the Windows app package;
  • MakeAppx: A switch that triggers the creation of the Windows app package;
  • Sign: A switch that triggers the signing of the Windows app package, with a generated certificate. This can be used for easily testing the created Windows app package;
  • Verify: A switch that triggers the verification of the Windows app package against the Desktop Bridge and Windows Store requirements.

Install_KeePassTest the application by installing the auto-generated.cer and simply double-clicking the created Windows app package (in my case MyKeePass.appx) and clicking Install.

Note: An alternative method is not signing the Windows app package and using the Add-AppxPackage cmdlet.


After creating the Windows app package, lets have a look at the results. There many things to look at, but, for this post, the most interesting thing is the created report (VerifyReport.xml). That report will provide a quick overview of the results for the created Windows app package. Below is the report available for the created KeePass app, on the left, and the report for a created Notepad++ app, on the right. A successful check on the left and a failed check on the right. The KeePass app shows no issues with the the Desktop Bridge and Windows Store requirements, while the Notepad++ app shows an issues with administrative permissions. An easy first check for a new Windows app package.


Deployment considerations

Now that the Windows app package is created it’s time to think about deploying the Windows app package. The most logical options are publishing the Windows app package to the Windows Store and using deployment tooling to distribute the Windows app package. The Windows Store can be used in combination with the Windows Store for Business and the deployment tooling can be one of my favorites, Microsoft Intune or Configuration Manager.

For publishing the Windows app package to the Windows Store, use this form to start the onboarding process. For distributing the Windows app package via Microsoft Intune and Configuration Manager, it’s important to sign the Windows app package. The used certificate must be of a trusted vendor, or must be installed in the trusted root/ trusted people certificate store.

More information

For more information about de Desktop Bridge and the Desktop App Convertor, please refer:

2 thoughts on “Using the Desktop App Convertor to create a Windows app package”

  1. Hi Peter, great post again. I was wondering, do you think that we should create UWP apps like this for deploying via Intune for example or that the application creator/owner should do that? We want to use only light deployment of Windows 10 desktops and are struggling with some common apps like Acrobat Reader as they do not provide a nice MSI or UWP (Yet?)

    • Hi Ronald and thank you. It completely depends on what you want to achieve. If it’s only for internal use, you can create the Windows app package yourself. Similar to when repackaging apps with App-V. However, if you intent to go the Windows Store (for Business) deployment-route than you should let the creator/owner of the app, create the Windows app package;


Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.