Testing a desktop app converted with the Desktop Bridge in the proper way

  • Article

If you have a desktop application that you want to convert, enhance or expand with the Desktop Bridge, the testing phase is critical. As you know if you have read the previous posts published on this blog, the Desktop Bridge doesn’t support yet all the scenarios of a desktop app (for example, you can’t deploy a Windows Service or a kernel driver) or enforces some best practices that Microsoft is suggesting to Windows developers since a while (like leveraging the AppData folder and not the installation folder to store user generated data, so that also non-admin users can use the application without permission issues). If you want to learn more, a great starting point is the official documentation: the following page describes all the constraints and requirements that a converted desktop app needs to satisfy https://msdn.microsoft.com/en-us/windows/uwp/porting/desktop-to-uwp-prepare

There are multiple ways to install and test a converted application. Let’s review all of them before highlighting some important information. The starting point will always be a folder which contains all the files that are required to generate an AppX package: a manifest file, the visual assets and all the files that are required by our application to run (executables, DLLs, the virtual registry file, etc.). This folder will always be part of your conversion process, no matter which was the starting process you used (an automatic one, using tools like the Desktop App Converter, manual conversion, etc.). If you want to do some tests and you want to start with a sample application, you can grab the folder called PackageLayout of the manual conversion sample in my GitHub repository: https://github.com/qmatteoq/DesktopBridge/tree/master/2.%20Manual/PackageLayout

Using PowerShell

One way to install and test your converted app is using PowerShell. It’s enough, in File Explorer, to open the folder which contains your converted app (like the PackageLayout folder of my sample) and choose File –> Open Windows PowerShell –> Open Windows PowerShell. powershell

 

PowerShell is a powerful language and it includes some commands which are specific to deal with Universal Windows Platform apps. One of the commands it’s called Add-AppxPackage and offers the option to install an application even if it isn’t package as an AppX, but just by specifying the path of the manifest file. In our case, since we have opened the PowerShell command window directly in the folder that contains our converted app, it will be enough to launch the following command:

 Add-AppxPackage -Register ".\AppxManifest.xml"

The application will be installed via side loading and it will be available in the Start menu, like any other application installed from the Store or by double clicking on an AppX. An advantage of this approach is that we won’t have to deal with certificates and package signing: no ones of the files inside the folder needs to be digitally signed in order to install the application, unlike when we want to side load a regular AppX. Additionally, if you need to make an update to your converted application, you don’t have to go through all the package creation – signing process: just uninstall the already installed version, change the files you have modified (like the executable of the app or one of the dependents DLLs) and execute again the PowerShell script. This way, the updated version of the converted app will be installed on your computer.

Additionally, once the application is installed and running and you own the original code, you can simply open the original desktop project and attach the Visual Studio debugger to the converted app, by using the Debug –> Attach to process menu.

Let’s make a real test by using one the samples I have published on my GitHub repository. Specifically, we’re going to use the HelloCentennial sample app, which source code can be downloaded from here: https://github.com/qmatteoq/DesktopBridge/tree/master/1.%20Desktop%20App%20Converter/HelloCentennial. This is the code of the original desktop version. However, if you open the solution then you launch the converted version you have previously installed through the PowerShell script, you will have the chance to leverage the code of the original version to debug the converted one. Simply put a breakpoint in your code, then from Visual Studio choose Debug –> Attach to process and, in the list, choose the process of your running converted app: then starts to perform some operations and you will see the breakpoints being triggered in Visual Studio. However, you are now debugging the converted version of the app and not the desktop one so if, for example, you start to enhance your app with UWP APIs (like we’ve seen in another post), you’ll be able to test and debug the new code and check for errors or unexpected behaviors.

debugger

 

Using the Desktop Bridge Debugging Project and Visual Studio 2017

If you have read the previous posts on this blog, this approach should already be familiar to you: we talked deeply about it in the blog post about manual conversion and we leveraged it also in many other steps of the Desktop Bridge journey, like Enhance or Expand. This approach is based on a special extension (which was previously called Desktop To UWP Packaging project) called Desktop Bridge Debugging Project which is available only for Visual Studio 2017 (which has reached the RC 3 milestone a few days ago).

You can download:

  1. Visual Studio 2017 RC 3 from https://www.visualstudio.com/vs/visual-studio-2017-rc/
  2. The Desktop Bridge Debugging Project extension from https://marketplace.visualstudio.com/items?itemName=VisualStudioProductTeam.DesktoptoUWPPackagingProject

I won’t discuss how this extension works in details in this blog post, since I already did it in the one about the manual conversion, which you can take as a referral. I will just remind you that this extension makes the whole debugging experience of a converted app much easier because it allows to create a new project in your solution, which will work side by side with the original project of the native desktop app. Thanks to this new project, you’ll be able to launch the converted version of the app directly from Visual Studio, like you would do with a regular project: just press F5 and you’ll be able to pause the execution with breakpoints, add watchers, see the details of exceptions that may arise, etc. And every time you need to apply some changes to the original desktop project, the Desktop Bridge Debugging project will take care of automatically copying all the changed build artifacts (executables, DLLs, etc.) in the folder which contains the converted version.

Always test the side loaded AppX version before releasing it!

All the options we’ve seen so far sound great, compared to the standard approach we have seen in the first part of the post about the manual conversion, which requires us every time to perform the following iteration:

  1. Make the changes in the desktop app
  2. Manually copy them in the folder that we want to convert into an AppX
  3. Use the makeappx.exe tool to create the AppX package
  4. Use the signtool.exe tool to sign the AppX package, so that we can install it

As such, our temptation could be to release our application on the Store, to share it to our colleagues or to deploy it using an enterprise tool without even testing the AppX we have generated. However, that would be a huge mistake and, thanks to PowerShell, we can have a hint of the motivation. PowerShell offers a command called Get-AppxPackage, which lists all the AppX packages that have been deployed to our machine. Let’s take a look at the result I get if I execute this command on my machine:

image

 

You can notice an important difference between an app that has been installed using one of the two methods highlighted before (PowerShell script or Visual Studio 2017) and an application installed through the Store or with a real AppX:

  1. In case of Slack, which is an application installed through the Store, the InstallLocation is the one we expect: it’s C:\Program Files\WindowsApps, which is the folder where all the AppX packages are installed.
  2. In case of HelloCentennial, which was deployed using PowerShell, the InstallLocation is the actual path of the folder we’ve worked with in order to generate our converted app, it isn’t the folder where standard packages are installed.

The consequence of the testing approaches described in this post it that some of the requirements of the Desktop Bridge we have mentioned in the beginning won’t be enforced: for example, if we try to create a file or a folder in the installation folder and not in the AppData one, we will be allowed to do that without encountering any issue. However, if we create the AppX and than we publish it on the Store or we share it with other colleagues, the app will start to raise exceptions and it will crash, because the AppX will be installed in the real deployment folder this time (C:\Program Files\WindowsApps) and, as such, every writing operation against it would fail.

Does this mean that the testing scenarios I’ve described before are useless and we are forced, every time we make a change to the original desktop app, to create the AppX, sign it and deploy it? Absolutely not, these approaches are still very valuable and they can help you to save some time and to identify faster and in an easier way potential problems. However, from time to time and, especially before releasing the package outside, remember to do a round of testing also of the real AppX package, because if you rely only on PowerShell or Visual Studio 2017 testing you may miss some issues.

If you have some experience with UWP development, this suggestion won’t be new to you: even with native Universal Windows Platform apps there are some scenarios that are enforced only when the app is running from a regular installation and not during the testing and debugging phase. For example, UWP apps are automatically suspended after 10 seconds they have been minimized, but if the Visual Studio debugger is attached this behavior isn’t enforced.

Happy testing!