Desktop Bridge – The bridge between desktop apps and the Universal Windows Platform

Article
10/13/2016

A couple of years ago, during the BUILD conference, Microsoft announced a technology called Project Centennial, which goal is to help developers to take their existing traditional desktop applications and to bring them to the Store, along with the native full Universal Windows Platform apps. Now Project Centennial has become a reality: it’s officially known as Desktop Bridge and, after months of testing, it has been officially released. As the name says, its goal is to create a bridge between the new development approach introduced in Windows 10 (the Universal Windows Platform) and the traditional desktop ones, based on Microsoft (like the .NET Framework, Windows Forms and WPF) and non Microsoft technologies (like Java, Delphi, C++, etc.)

The Desktop Bridge release has been made possible also thanks to the release of the Anniversary Update: the last Windows 10 update, in fact, contains, under the hood, all the technology needed by Win32 application to run inside the Universal Windows Platform container. The Desktop Bridge was officially launched on 14th September 2016, together with many announcements.

The Store opens the door to the first converted applications

Starting from 14th September, you can actually download from the Store real desktop apps and not just native Universal Windows Platform apps. Up to today, there are more than 40 converted apps available on the Store, including some very popular names like Evernote, Kodi, Open Live Writer and Arduino IDE. You can check a collection of some of the most popular converted apps here: https://www.microsoft.com/en-us/store/collections/fullsoftwareapplications/pc

The Desktop App Converter is now available on the Store

Previously, the Desktop App Converter was available only as a regular download and based on a Powershell script, which you needed to maintain updated over time. Now, instead, the tool is available directly on the Store and you can install directly from the following link https://www.microsoft.com/store/apps/9nblggh4skzw. This is the best way to get tool since, every time the Desktop Bridge team will push an update, you will automatically get it, as it happens for every apps that you can download today from the Store.

AppX is now supported by some of the most popular installer tools

On the market there are many popular tools used by developers to create installers for their desktop applications, like InstallShield, Wix or Advanced Installer. All the latest versions of these products are now capable of exporting the installer not just using the traditional formats, like EXE or MSI, but also directly using the AppX model.

I’m a .NET desktop developer, why should I be interested into using the Desktop Bridge?

This is a very common question I receive when I speak or write about this technology: my desktop app works just fine, why should I be interested into porting it to the Universal Windows Platform using the Desktop Bridge? Additionally, we know that the Universal Windows Platform is a new framework that ensure a much better deployment and security model than traditional apps, thanks to its sandbox, but it also means that sometimes it can make things more complicated when it comes to deal with some scenarios that we often have to handle in an enterprise environment.

These are really good questions, so let me help you to understand why the Desktop Bridge is a huge deal for every desktop developer out there!

The digital transformation

We moved from a PC centric approach to a mobile world, where everyone (no matter if we’re talking about a young, middle age or old person) is always connected to Internet through a smartphone or a tablet. Consequently, this shift created a huge gap between the way developers and users handles applications on a smartphone or on a PC: from one side, all the main platforms offers a Store where the user can simply search for apps and tap on a button to install and uninstall them. On the other side, instead, most of the times the user has to open its browser, look for the name of the application on a search engine, manually download a setup file and follow a guided wizard, which can be more or less complicated. In this process, the user also needs to pay attention that he has downloaded the real application and not a fake one that, under the hood, it acts as a virus or a malware. As such, the Store approach has introduced many advantages both for users and developers: for the firsts, it’s much easier and secure to find and install new applications; for developers, it’s easier to make their applications more visible and to monetize them, since they can leverage the existing infrastructure instead of having to create their own payment and license backend. The same applies for the deployment model: if we want to release an update, it’s enough to upload a new package on the developer portal offered by all the platforms; it isn’t our responsibility to implement an auto update feature within the app. It’s also easier to make sure that our customers are using the latest version of our product, making easier to support them.

A better deployment process: solving DLL hell, registry and file system bloat

We know that, many times, the install / uninstall experience provided by traditional desktop applications isn’t really smooth Most of the times, the uninstall procedure doesn’t remove all the registry and file system entries, because it may happen that they are shared with other applications. Another common problem is when multiple applications have a dependency from the same DLL and, at some point, one app updates it to a newer version, breaking all the other applications. The Universal Windows Platform deployment model, instead, doesn’t suffer of these problems: the application runs inside a container and, as such, the file system and the registry are virtualized and merged, in real time, with the real registry and file system. As such, every application has its own set of DLLs, registry keys and files, so there’s no risk of mixing them. Additionally, both the update and the uninstall process are much smoother: in the first case, you just install an updated AppX and you overwrite the files that have changed; in the second case, you just delete the folder where the app was installed and the one where the local app data is stored.

A modern development runtime

The .NET framework has born in a technological context very different from the current one: the mobile experience, the cloud, the Internet of Things aren’t just buzz words, but they are real technologies that are spreading more and more in the latest years. From this point of view, the Universal Windows Platform has a lot to offer: it’s a modern development platform, which is able to run on many different devices (computers, tablets, smartphones, Xbox One, HoloLens, etc.), and which makes easier to create performant and beautiful applications; it offers visual tools (like Composition APIs and the XAML Adaptive Triggers) that help to create modern user interfaces, which are able to easily adapt to different screen sizes and to the new generation of devices, which propose resolutions and DPIs higher than ever; it includes APIs to easily implement new ways to interact with the application, like inking, speech interaction, push notifications, etc.

Many of these changes are often requested also in enterprise scenarios not just because the customer wants to follow the latest trends, but because the digital transformation has brought a deep change in the way many people work every day: it’s hard to find a company that, at least, hasn’t started to consider to modernize its IT infrastructure and to start expanding their offer, by adding to the classical desktop application also a new set of tools that can be used by mobile workers, who need to leverage cloud, data synchronization, touch interfaces, etc. In all these contexts, Windows 10 and the Universal Windows Platform can offer, without any doubt, something more than traditional Win32 apps.

Which are the approaches offered by the Desktop Bridge?

There are multiple approaches to use the Desktop Bridge. The key message to take away is that, as a developer, you can move at your own speed and you can decide to stop at the phase which satisfies best your requirements. You aren’t forced to go through all the steps and, if you wanna do it, that’s great because in the end you’ll get a full UWP app, but you can take the time you need to adjust every step based on your scenario. It’s important to highlight also that a desktop converted app is be able to run only on computers and tablets with the full Windows 10 Anniversary Update version: only when you migrate it to a full UWP app, you’ll be able to launch it also on the other devices of the Windows 10 family, like Xbox One or HoloLens. The reason is that the desktop version of Windows is the only one that, other than including the Universal Windows Platform, contains also all the needed runtimes and frameworks to run Win32 apps. Let’s see a brief overview of the various opportunities, in the next posts we’re going to see them in details.

Desktop App Converter, which is the tool we already mentioned that is able to take an existing installer and to convert it into an AppX package, that you can install on other Windows PCs or publish on the Store. This approach doesn’t require any change in your code, even if there is a set of requirements that your app needs to satisfy (like supporting a silent installation mode, doesn’t requiring to install kernel drivers or NT services, doesn’t trying to write in the application folder, etc.). All the requirements are listed in the official documentation at the URL https://msdn.microsoft.com/windows/uwp/porting/desktop-to-uwp-root. As developers, the main advantage of this approach is that you can reach more customers (thanks to the Windows 10 Store) and you can implement in a much easier way many deployment and monetization scenarios (selling the app, offering in-app purchases, releasing updates, etc.) which, in a typical Win32 application, you would need to implement on your own with a custom solution. Users, instead, will benefit of a much easier installation and uninstallation process. In the above image, the Desktop App Converter is the key of the step called Convert, even if it isn’t the only option: in the next posts we’re going to learn that we have also the chance to manually create an AppX package starting from a Win32 executable, even if it doesn’t have an installer.
Expand a desktop application with the Universal Windows Platform. With this approach, you have the chance to take the source of your desktop application and, without rewriting it as a Universal Windows Platform app, you can start adding some UWP features: this way, the application can continue to work as a regular Win32 application (and perform operations like reading and writing from the registry or using any other API of the full .NET Framework) but, at the same time, start to leverage some specific Windows 10 features. You can decide just to use some UWP APIs (like sending a toast notification, updating the tile, using speech services, etc.): in this case, we’re talking about the Enhance phase. Otherwise, you can start to add full Universal Windows Platform components, like background tasks, app services or XAML UI parts. In this case, we’re moving to the Extend phase.
Integrate a Win32 process inside a UWP application: with this approach (which is identified in the image by the Migrate step) you already moved to the next phase. You don’t have anymore a desktop app that integrates with the UWP world, but the opposite: a full UWP application that, however, needs to perform some specific tasks when it runs on a desktop computer. There are many sample scenarios: for example, you have ported to UWP a very complex Windows Forms application and there’s one specific form which would require a huge amount of work to be rewritten and, as such, for the moment you want to keep the original version. Or maybe, when the application is running on a computer, you need to interact with the user in some special ways which aren’t allowed by the Universal Windows Platform at the moment, like having a blinking icon or displaying a progress bar in the taskbar. With this approach, the UWP app will be able to invoke a Win32 process and, by leveraging App Services (which are special background tasks that can be used to create a communication channel), you can exchange data between the two applications. The best part of this approach is that you have in your hand a full UWP app, which can be deployed also on a phone, on a HoloLens or on a Xbox One. However, only when it’s running on a desktop, you can take advantage of this specific Win32 process.
Reach all is the ultimate goal, which means converting the original application into a full UWP app. To reach this goal, there’s work to be done both by developers and by Microsoft. From a developer point of view, you need to start thinking about app development in a different way. There are many scenarios where some .NET features have been replaced by more efficient and modern approaches in the Universal Windows Platform. For example, many apps used to store settings in the registry: a UWP app doesn’t need the registry, because it has a reserved location where to save settings, that can also be shared across multiple devices. Or, again, the Anniversary Update has introduced a special kind of storage that is shared across every app published by the same developer, where you can read and write data without having to rely on the registry or other folders on the system. From a Microsoft point of view, the Windows team is committed into making UWP more and more the best choice when it comes to develop a desktop app, so you can expect in the next SDK versions a special attention to desktop application, without forgetting at the same time the advantages of the better security and deployment model offered by the Universal Windows Platform.

Distribute converted applications

So far, we’ve talked about the Store opportunity for converted apps, but in some scenarios (especially the enterprise ones) you don’t need a Store to distribute your apps, but more private ways. The good news is that the Desktop Bridge, together with the Anniversary Update, can be a great choice also for applications that aren’t released through the Store. In the past, Microsoft has always offered the chance to side load AppX packages, but there were some challenges: in Windows 8, you were required to buy some special licenses to enable it; Windows 10 has removed this requirement and now you can turn on the sideloading option directly in the Settings but, before the Anniversary Update, you needed to run a set of Powershell scripts to actually install the package; the November Update has introduced the Windows Store for Business, which is a private version of the public Store dedicated to enterprises. It’s the best and easiest way to distribute applications within your company, but your IT infrastructure needs to satisfy a set of requirements (like adopting Azure Active Directory), which can’t be given for granted. The Anniversary Update has introduced a new and important step forward to make distribution even easier: now the AppX packages are self executable files, like any other installer. You can just double click on it on any Anniversary Update computer and start the installation process.

The only requirement, from a security point of view, is that the AppX has to be signed with a valid digital certificate: you can choose to buy one from a public certification authority (in case you want to distribute your application to a wide audience without using the Store) or you can create a self-generated certificate (in case you want to distribute your application to a small set of users or within your company). However, this isn’t something new: also standard installers need to be signed with a valid certificate, otherwise Windows, for security reason, will try in any possible way to prevent you installing the app, since it isn’t trusted.

The same exact process applies to native UWP apps, it isn’t a specific requirement of converted apps. However, if you have only used the Store, so far, as distribution platform, everything has always been “hidden” since, when you publish an AppX package on the Store, you don’t have to deal with certificates, since the Dev Center will automatically take care of digitally signing the AppX for you during the ingestion process.

In the end, one of the main advantages of the new AppX format is that, as a developer or as an IT Pro manager, you can distribute your apps in multiple ways:

You can publish it on the Store, to have more visibility and to make your life easier when it comes to handle monetization and updates.
You can create scripts to automatically distribute the app on a set of computers that belong to the same domain.
You can use Mobile Device Management tools like Microsoft Intune to handle company devices and distribute apps in a centralized way.
You can upload the AppX on a website or on an Intranet and share the URL with your customers.
You can even copy the AppX on a USB Drive and manually install it on every single PC.

The Store distribution

One important concept to highlight is that, at the moment, not every developer is allowed to submit desktop apps on the Store, but they need first to get approval by Microsoft. The main reasons for this requirement are:

Security: even if converted apps run inside a container, they are still executed in a full trust mode and, as such, they’re capable of performing potentially malicious operations that a regular UWP app can’t do. As such, as Microsoft, we want to make sure that the Store continues to be a trustworthy and reliable place for users.
Legality: Desktop App Converter allows to take any existing installer and to convert it into an AppX package since, of course, the tool can’t determine if you’re the real owner of the application. Consequently, again, we want to make the Store a reliable place and, as such, we want to make sure that if you want to publish a converted app on the Store, you’re the real owner of the project and of the source code.

If you have a desktop application or a game that you would like to bring on the Store using the Desktop Bridge, you can fill the following form: https://developer.microsoft.com/en-us/windows/projects/campaigns/desktop-bridge. A Microsoft team will evaluate your application and, if it gets accepted into the program, a person of the AppConsult team will reach you and will help you to solve any technical blocker and to move on with the legal process required to publish converted app. Any tentative of submitting a converted app, right now, will be rejected, since these special apps leverage a restricted capability (called runFullTrust) . Consequently, as soon as you’ll try to upload the AppX in the Packages step of the submission process on Dev Center, you’ll get an error and you won’t be able to move on with the other steps.

Wrapping up

In this first post we’ve learned why, as a desktop developer, you shouldn’t underestimate the Desktop Bridge and why it can be a great choice to start modernizing your applications, no matter if we’re talking about a consumer or a business application. In the next posts, we’re going to explore with more technical details each phase of the conversion process, starting from the Desktop App Converter. Stay tuned!

Happy coding!