If you’re working since a while with the Desktop Bridge to convert classic desktop applications in Universal Windows Packages that can be, other than distributed using traditional channels, also published on the Store, it may happened that you have stumbled across the following error trying to manually install an AppX file for testing purposes:
This error is very common when you have used, as a starting point, the Desktop App Converter to convert an installer or a self-executable application, then you have applied some changes and you have recreated the package using the makeappx tool as explained in the section titled Repackaging the app in the following blog post: https://blogs.msdn.microsoft.com/appconsult/2016/10/17/desktop-bridge-converting-an-installer/ ...
The reason is that the latest version of the DAC, other than just converting the application, is able to extract its main icon and to generate all the required assets from it. However, the tool doesn’t simply take care of the images in the various required sizes (like the icon for the Start menu, the various tile formats, the icon for the taskbar, etc.), but it also takes in consideration the different scaling factors supported by Windows 10. One of the biggest challenges for classic and modern apps is that there’s a wide variety of computers out there, with an increasing number of models with screens that offer a very high resolution and DPIs. Just as an example, I’m writing this post from a Surface Pro 4, which has a 12.3’’ screen and a 2736x1824 resolution. Without a scaling system in place, my device would be really difficult to use, because everything would be too small to be visible due to the very high resolution on such a relatively small screen. As such, Windows 10 offers a built-in scaling system, which can be leveraged also by developers, in order to make sure that applications are still usable despite the screen configuration of your device. You can check the scaling factor assigned by Windows simply by going into Settings –> System –> Display. In the section titled Scale and layout you can find all the information you need. For example, the below screenshot is taken from my Surface Pro 4: as you can see, Windows 10 has assigned a 200% scaling factor to my device.
When the Desktop App Converter generates a converted version of your application, it creates also a version of every asset specific for each scale factor. As such, if you enter into the Assets subfolder of the PackageFiles folder generated by the tool, you will find that the same image (for example, the one used for the wide tile called AppWideTile.png ) will be available in multiple version, each of them with a different suffix that refers to a specific scaling factor (like AppWideTile.scale-100.png , AppWideTile.scale-200.png , AppWideTile.scale-400.png , etc.). Why not simply generating an image at the highest possible resolution and use it on any device? To optimize the deployment and downloading phase. If you look at the content of the PackageFiles folder you will find that, other than the files that belong to your application, there’s a set of resources files , which are identified by the .pri extension. Thanks to these files (which maps all the available resources), during the deployment / downloading of the application, the user will get only the resources which are correct for his device. This way, for example, a user with a traditional laptop with a Full HD screen (1920x1080) won’t download the assets dedicated to devices with 4K screens, saving space and bandwidth.
Now that we have understood the work done by the Desktop App Converter, let’s go back to our original problem and understand why we might get the initial error trying to sideload an app package. The tool applies to these resource files a signature, which is generated based on some information from the manifest file, like the Identity of the app. As such, the most common scenario where you can face the initial problem is the following one:
To solve the problem, you need to recreate the resources files from scratch.
The first step is to delete, inside the PackageFiles folder generated by the Desktop App Converter, all the existing resources, which are all the files with .pri extension. Then you need to open the Visual Studio developer command prompt, that you can find simply by start typing “developer” in the Start or Search menu: the prompt to open is called Developer Command Prompt for VS20XY (which can be VS2015 or VS2017, based on the Visual Studio version you’re using).
Then you need to launch the following two commands. The first one is:makepri createconfig /cf priconfig.xml /dq en-US
You need to launch this command inside the PackageFiles folder, so make sure that you have used the cd command to move to the output folder created by the Desktop App Converter before launching it.
Then you need to launch the second command:makepri new /pr <PHYSICAL_PATH_TO_FOLDER> /cf <PHYSICAL_PATH_TO_FOLDER>\priconfig.xml
In this case, instead, it doesn’t matter where you launch the command, because you will have to replace the <PHYSICAL_PATH_TO_FOLDER> placeholder with the full path of the PackageFiles folder. For example, considering the previous Desktop App Converter sample command (which has generated the output in the C:\ExpenseIt-AppX folder), the command to launch would be:makepri new /pr "C:\ExpenseIt-AppX\ExpenseIt\PackageFiles" /cf "C:\ExpenseIt-AppX\ExpenseIt\PackageFiles\priconfig.xml"
That’s all. If you have done everything properly, you should find now, in the PackageFiles folder, a new set of resources files which, however, this time have a signature that matches the identity of the application. As such, if you generate a new app package using the makeappx tool and then you double click on it, this time you’ll get as result the expected experience:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.