Distribute Desktop Applications in the Modern World with the Help of Desktop Bridge

Written by Matteo Pagani (guest) · April 13th, 2017

The digital transformation has changed the way users work across a new generation of devices. If in the past, traditional computers were the only gateway to the digital world for both enterprise and traditional users, the mobile revolution has changed the way people access to digital information: smartphones and tablets have become, more and more, a companion to traditional desktop apps. However, despite this transformation, there are still millions of desktop solutions on the market and the enterprise-ready devices with a mouse and a keyboard are still the most effective way to achieve full productivity.

It’s undeniable, however, that the rise of the mobile market has created a barrier between the mobile and the desktop worlds, which is reflected both in the user and software vendors’ experience. On a smartphone, users rely on a centralized distribution system (a Store), which is handled by the owner of the platform, giving a more trustworthy and reliable monetization and acquisition approach for the user. Additionally, the overall deployment experience is very easy: the user typically opens the Store, searches for the name of the app and, with one button, he’s able to install or fully uninstall an application, etc. From a developer point of view, this new approach has simplified a lot of many scenarios that, in the past, needed to be manually handled: creating an installer, setting up a selling system, providing an update system, etc.

This new approach has created a demand, even with classic desktop applications, for increased security, an easier way to purchase, install and update them, a clean uninstall experience and better integration with the powerful productivity features of Windows 10.

This is the scenario where the Desktop Bridge comes in. It’s a new technology announced at BUILD 2016 but officially launched and included in the Windows 10 Anniversary Update, which allows to take an existing desktop application and package it using the same deployment model leveraged by the Universal Windows Platform, the new development platform introduced in Windows 10. Thanks to this new model, we can reach the goal to keep our desktop application as it is, without having to change our code or rewrite it and, at the same time, leverage all the benefits of the Universal Windows Platform, like a safer and cleaner deployment technology, access to new features, a better integration with the Windows 10 ecosystem, etc.

Let’s see which are the key pillars that the Desktop Bridge allows us, as developers, to achieve.

A better deployment model

Traditional installers have always suffered from a set of historical weak points that, if not used in the proper way, can ruin the user experience. Let’s see some of them:

1. The requirement, for the developer, to take care of the deployment phase other than the development of the application: if you want to create a desktop application, developing it isn’t enough, you have also to take care of authoring the installation experience. This is where tools like Advanced Installer are very useful and they can make the developer’s life easier, by offering options, for example, to automatically generate an installer directly from a Visual Studio project. However, it’s still an extra step: it’s the developer in charge of creating the optimum installation experience, not the operating system. The Desktop Bridge helps to solve this problem because it’s able to take an existing Win32 application and convert, as it is, in a Windows 10 app package. Windows 10 can automatically handle the deployment of these packages, no matter which is the distribution channel you’re going to use: as a developer, you just need to develop your application and package it into an AppX file. It will be Windows 10, either from the Store, from a manual side loading or from an enterprise tool, to take care of the overall deployment phase (installing files in the proper folder, register the app in the system, creating an entry in the Start menu, etc.)

2. A potential dirty install and uninstall experience: many desktop applications make an improper usage of the registry or of some of the folders on the user’s machine, for example, to store settings or to share data with other application. As such, to avoid the risk of making other applications’ unstable, many installers simply decide to not fully clean all the registry keys and the files that belong to the application when it’s uninstalled, even the ones that wouldn’t make sense without the application itself (a set of log files, some temporary data, a custom database, etc.). This can lead, over time, to degrade the Windows experience, by filling the hard disk of the user with useless data and by slowing down the execution and the loading times of the operating system. The Desktop Bridge enforces a set of features that helps to prevent these problems like:

• Redirecting all the writing operations from the system registry to a binary file that is specific for the application.
• Copying all the files that are part of the app package inside a folder that is protected and hidden to a regular user.
• Redirecting all the writing and reading operations performed against the AppData folder to a local and isolated folder specific to the application.

As such, there are no 3rd party uninstall tools involved: when you decide to uninstall a converted app, Windows will simply takes care of deleting all the previously described files, with no leftovers behind (except, of course, for the files that the application has created outside the AppData folder, like an exported PDF in the Documents library or an image saved in the Pictures library).

3. DLL hell: with this expression, developers refer to a common problem that happens when multiple applications depend on the same set of files (like a framework or a library), which are installed system-wide (one copy for the overall system). When all the applications that have such a dependency are using the same version of the framework, the situation is under control. However, as soon as we install an application that requires an updated version of the framework and the setup, other than installing the application itself, takes care of uninstalling the existing framework and replacing it with a newer version, it may break all the existing applications. This problem is solved by a Virtual File System provided by the Desktop Bridge: every app package can contain a special folder called VFS, which maps the most common system folders (like Windows, System32, System64, Program Files, etc.). Whenever your converted app will look for a dependency, like a framework, it won’t search for it in the system, but inside this VFS folder, which is isolated and specific for each app. This way, every app will have its own version of the dependency, without risking of breaking other applications that depend from the same framework.

A safer user experience

Traditional desktop applications have the option to run with administrative rights and, as such, they can perform potentially malicious and dangerous operations, like deleting system files or changing system registry keys. A desktop app converted with the Desktop Bridge enforces a set of requirements that help to make the user experience safer for the customer: it can’t elevate itself as admin, it can’t write in admin protected folders, it can read supported system registry hives, but it can write only to a binary registry file. Additionally, Microsoft has a set of guidelines that is suggesting to Windows developers since many years to make the overall user experience better and safer, like writing any user-generated data that is tightly connected to the application inside the AppData folder and to not use the installation folder, because typically it requires administrative rights to be accessed. The Desktop Bridge takes care of enforcing these requirements: if in a regular desktop app, you can choose to bypass them (for example, by using UAC to require admin elevation), a converted app will simply return an exception. As such, the Desktop Bridge, other than helping you to provide a better experience to your customer, will help you to think the architecture of your application in a better and more modern way.

New distribution channels

Another “disconnection” from a user experience point of view between desktop and mobile apps is how easy is to get an app on a mobile device, compared to the experience on a traditional computer: you need to open a browser, open a search engine, look for the name of the app, pay attention that you’re downloading the installer from a trusted source, etc. Not to mention that everything related to the lifecycle of the application is on your own: you have to provide a reliable and safe way for the user to purchase your app and to handle the licenses; you must support automatic updates, if you want to make sure that your customers are always using the latest and greatest version of your application; if you want to get telemetry, feedback, and crash reports, you have to create your own backend infrastructure or implement a 3rd party telemetry system. The Desktop Bridge allows you to keep leveraging the existing channels, so you can still give the chance to your customers to download the app package from a website or to distribute it using popular enterprise tools like Intune, Airwatch or System Center Configuration Manager. However, in addition, you can also leverage new and modern channels, like the Windows Store or the Windows Store for Business, which solve many of the challenges previously outlined:

1. The monetization of the app is handled directly by Microsoft, and it supports also to use local payment methods and to easily enable new purchase models, like a time-based trial or paid add-ons.

2. Applications automatically update themselves: just submit an updated version of the app package on the Store and, in a few days, every Windows 10 user who has installed your application will get the new version.

3. Out of the box, the Store collects in an anonymous way crashes, download statistics, conversions from free trial to the paid version, etc.

4. Thanks to the review system, you can easily collect feedbacks from your customers and decide which are the features of the application where you should focus more on the next updates.

5. The Store supports advanced distribution scenarios, like:

• Promo codes to give the app for free to testers, reviewers, tech journalists, etc.
• Flighting distribution, which allows distributing preliminary updates of your application to a restricted number of testers.
• Gradual rollout, which allows to gradually release a new version of the app to your customers: this way in case you identify reports of a severe bug that you didn’t catch during the test phase, you can halt the release phase and minimize the negative impact of the bug.

Integration with Windows 10

The Universal Windows Platform, other than being the new main development platform to create modern applications that can run, other than on traditional desktop computers, also on a variety of devices powered by Windows 10, like phones, HoloLens, Xbox One, etc., is seeing more and more investments to include new features that can help an application to integrate better with the Windows 10 ecosystem. Windows Hello for security, Windows Pen & Ink, Cortana for speech services, live tiles, push notification are just an example of some of the features that can increase the engagement of your customers with your application. Before the Desktop Bridge, the usage of these new features was restricted to applications written for the Universal Windows Platform, which is very powerful but, at the same time, it’s also a different way to write applications for Windows, so if you have a very complex enterprise app based on WPF, Windows Forms or any other Microsoft or non-Microsoft development platform, the migration path can take some time.

Thanks to the Desktop Bridge, a Windows desktop app can continue to run as it is but, at the same time, it runs inside the context of a Universal Windows Package. This means that the app, even if it isn’t running in a sandbox like a real UWP app, now has an identity and, as such, it’s able to leverage APIs and components from the Universal Windows Platform directly from the win32 process, no matter which is the technology behind it: .NET Framework, Java, Delphi, Electron, etc.

The Desktop Bridge as a journey

The Desktop Bridge can be seen not just as a technology, but also as a journey: once your desktop application has been converted into an app package, there isn’t any limit to what you can do: you can enhance it with new Windows 10 features; you can leverage some powerful, safe and optimized Windows 10 components (like background tasks and app services) in a desktop app; you can create a Universal Windows Platform app, capable of running on every Windows 10 device but, at the same time, only when it’s launched on a traditional computer, it can still interact with a Win32 process.

The best part of this journey is that you’re in charge of it: it’s you, as a developer, that can decide how much fast you want to move, and which step you want to reach. Of course, the more code you move to the Universal Windows Platform, the easier for you will be to leverage new features, new technologies, and new deployment models, but no one will force you to do that if you think that, for your project, it’s better to keep using the current technology and leverage just some of the new features.

How can I convert an application?

There are multiple ways to take an existing desktop application and convert it into an app package. The official Microsoft documentation lists many of them:

• Desktop App Converter, which is a tool by Microsoft that can process an installer or a folder containing a self-executable application, detect all the changes made during the setup process (like the creation of registry keys of the installation of dependencies) and generate an app package out of it.
• Manual conversion, which means that it’s up to you to create all the files that you need to place, side by side together with your traditional desktop application, to turn it into an app package.
• Visual Studio, which includes a set of tools that can help you to generate an app package starting from an existing application developed with a Microsoft technology.

How can Advanced Installer help?

As we have learned at the beginning of this post, one of the requirements of a desktop developer is that, other than overseeing creating the app itself, he needs to take care of authoring the installation process. As such, it’s very likely that, if you have an existing desktop application, you already have an installer in place, created with a 3rd party tool like Advanced Installer. Thanks to this tool, you have already defined everything that is required by your desktop application to be properly installed: registry keys that must be created during the installation, file explorer integration, desktop and start menu shortcut creations, etc.

Why not reusing the definition of the setup process we have already created to generate an app package out of the box? Here comes the new Desktop Bridge integration offered by Advanced Installer, which supports to take an existing installer project that may have already created to generate a traditional MSI installer and to use it to create an app package directly within the tool. Even better, you can do it also within Visual Studio itself, thanks to a free extension developed by the company (you will find a specific version for each Visual Studio release).

Let’s see a quick example of how to achieve this goal. Let’s say that you have an Advanced Installer project, which is configured to take care of generating an MSI based on a desktop app you have previously created, like in the following screenshot:

On the left, you can see the panel where you can customize all the properties of your installer, like the folders that must be created, which files must be copied, the registry keys to be added to the system, optional dependencies from popular frameworks, etc.

The real work happens in the section called Builds, where you can configure multiple build outputs, based on the installer you want to generate: the above screenshot shows you a standard configuration that generates an MSI installer called ExpenseIt.msi. At this point, with the standard Desktop Bridge approach, you should take this MSI installer, run it through the Desktop App Converter tool by Microsoft and generate an app package starting from it. But let’s look more closely at the top bar of Advanced Installer:

As I’ve highlighted in red, there’s a new option called UWP AppX Build. Click on it and, other than the standard configuration to generate a MSI installer, you will find a new option in the section below to automatically generate an AppX file starting from the same installer definition.

Now, if you simply right click on the new build definition (the one called BuildUwpAppX in the Builds section in the screenshot) and you choose Build, Advanced Installer will leverage the Desktop Bridge and create for you, out of the box, an AppX package ready to be installed, distributed, published on the Store, used for testing, etc.

But there’s more: if you click on one of the links in the Content section, like Applications or Declarations, you’ll be redirected to a visual editor of the manifest, which is the file that describes the features of the application, and it’s split into multiple sections:

Thanks to this visual editor, you will be able to easily define:

1. The identity of the application, like the publisher name, the unique identifier, etc. This information is very important both in case of Store distribution (they should match the values assigned by the Dev Center when you have reserved the name for your app) and enterprise distribution (they should match the values of the enterprise certificate that will be used to sign the package).

2. The visual assets, which are the icons and images used for the Start menu, the taskbar, the main tile, etc.

3. The usage of special declarations: in the Universal Windows Platform world, declarations are what make possible for an application to interact with the operating system or other applications. Some examples are background tasks, app services, the share contract, etc. In addition to these declarations, the Desktop Bridge has introduced a set of special extensions, which are used to handle typical desktop scenarios that, in a regular app, would be handled with special registry keys that must be registered with administrator rights, like:

• File Explorer integration
• Protocol association
• File association
• The option to launch the app startup

Can Advanced Installer help me to distribute my app?

The answer is yes! One of the key requirements for an app package to be installed on a Windows 10 machine is that it must be signed with a digital certificate, which must be trusted by the machine where you’re deploying the AppX file. It can either be a self-generated certificate (for testing scenarios or enterprise deployment) or purchased by a certification authority. Thanks to the Digital Signature section of Advanced Installer, you can pick up your certificate (typically, a .pfx file) and use it to sign the AppX file during the generation process.

The only exception is if you want to submit your application on the Windows Store or Windows Store for Business: in the case, the package doesn’t require to be signed, because the Store will automatically take care of it during the submission process. However, at the current time of writing, a developer with a regular Dev Center account can’t submit a desktop app converted with the Desktop Bridge, for security and legal reasons. The technical blocker is that, if you look at the manifest file (the one called AppxManifest.xml) or at the Capabilities section of the visual editor provided by Advanced Installer, you’ll notice that it’s declared a special capability called runFullTrust:

This capability is the one that makes possible, for a desktop app, to keep using all the Win32 APIs and resources, even if’s running inside a package of the Universal Windows Platform. It’s a restricted capability, which means that if you try to submit an AppX file that uses it the Dev Center will reject it, and it won’t allow you to complete the submission process.

As such, if you want to see your converted desktop app on the public Windows Store, you must nominate it as following: you will be contacted by a Microsoft engineer from the AppConsult team that, other than supporting you in the conversion process in case you are facing any technical challenge, will make sure that your app is compliant and will guide you through the process of unlocking your account.

Wrapping up

The Desktop Bridge is really a powerful technology and, if you are a desktop developer, you should not miss all the benefits that it can give to create better, more modern and safer applications, no matter if you’re targeting consumers or enterprise customers. As we have learned in this post, Advanced Installer is the perfect companion to this technology: if you already have an installer project for your existing desktop app and you want to leverage it, it’s a matter of a few clicks to generate an AppX package together with the existing installer technology you already have, so that you can get the best of both worlds and keep supporting all your customers, no matter which version of Windows they’re using.

Happy conversion!