In the previous post we’ve learned how to convert the installer of a traditional desktop application (based on Win32 technologies like the .NET Framework, C, Delphi, etc.) in an AppX package, so that we can start to leverage the best of both worlds: the maturity of the Win32 frameworks and the better security and deployment model offered by the Universal Windows Platform.
In some cases, it may happen that your application leverages some native code or that has a dependency from a component written in C / C++ and, as such, to run properly, it requires that the final user has installed the Visual C++ libraries on his system. Many traditional installers takes care of this, by offering to the user to download and install them if they aren’t available in Windows.
How is this requirement managed for converted applications? First, to understand if you are in such a scenario, it’s enough to keep an eye on the output of the Desktop App Converter at the end of the conversion process. If your application has such a dependency, you will see a message like the following one:"Warning Summary:
The message is quite self-explanatory: the Desktop App Converter has found a dependency from the version 14.0 of the VC libraries (which is required to run native components) and, as such, has modified the manifest file in order to support this requirement. You can easily notice this by opening the AppxManifest.xml file which is included in the PackageFiles folder created by the tool. In fact, under the Dependencies section, you will find the following entries:<Dependencies>
As you can notice, other than the standard dependency from the 14393 SDK of the Universal Windows Platform, you will find a new dependency from a package which name is Microsoft.VCLibs.140.00.UWPDesktop and published by Microsoft. The name of the dependency may change, because some apps may depend by older versions of the VCLibs, like 12.0 or 11.0. In this case, instead of Microsoft.VCLibs.140.00.UWPDesktop you will find another name like Microsoft.VCLibs.120.00.UWPDesktop .
The problem is that if, right now, you would try to install the AppX you’ve just generated, you will get an error, since the package isn’t able to find all the required dependencies. The reason is that, by default, the UWP version of the Visual C/C++ libraries used by the Desktop Bridge aren’t installed in Windows 10 Anniversary Update. The output message displayed by the Desktop App Converter, in fact, invites you to visit the following page: https://blogs.msdn.microsoft.com/vcblog/2016/07/07/using-visual-c-runtime-in-centennial-project... It’s a blog post from the Visual Studio team, which explains how these dependencies are handled but, especially, it provides a link to download the different UWP libraries, based on the various available versions of the VC ones:
You will need to download the proper version based on the warning message that was displayed by the Desktop App Converter at the end of the conversion process and on the dependency that was added in the manifest file. For example, in the previous scenario, the tool has added a dependency to a library called Microsoft.VCLibs.140.00.UWPDesktop , as such you will need to download the VC 14.0 framework package (the first of the three links of the list). If the dependency would have been from the VC 12.0 framework package, you would have downloaded the second and so on.
Regardless of the version you have downloaded and installed, the setup process will create a folder inside the path C:\Program Files (x86)\Microsoft SDKs\Windows Kits\10\ExtensionSDKs\ for each version of the library. For example, if you have installed the 14.0 version, you will find the UWP version you need in the path C:\Program Files (x86)\Microsoft SDKs\Windows Kits\10\ExtensionSDKs\Microsoft.VCLibs.Desktop\14.0\Appx\Retail
This is the key operation to complete the installation of the dependency: many developers fall into this “trap” and they think that installing the downloaded setup is enough. Instead, inside the folder, you will find a version of the library for each architecture: in our case, we are interested only in the x86 and x64 versions, since desktop apps converted using the Desktop Bridge can’t be executed on devices based on the ARM architecture (like phones or a Raspberry Pi). Consequently, open both the x64 and x86 folders, where you will find an AppX file with a name like Microsoft.VCLibs.x86.14.00.Desktop.appx (of course, instead of 14.00 you could find 12.00 or 11.00 as release numbers, based on the VC version used by your app), then double click on the AppX and proceed with the installation, like if it’s a normal application :
The only difference is that, at the end of the installation, when you’ll be prompted to Launch the application, don’t do it, because it won’t have any effect: we’re talking about libraries and not a real application that can be executed in a traditional way. Only at this point the dependency will be really installed and you will be able to install the app package. Under the hood, the procedure will have installed the dependencies that were required by the original app you have converted: consequently, you will now be able to try again to install the original AppX and, this time, the operation will complete just fine.
Another confusion case can happen if you install multiple versions of the framework package, simply because you may have multiple apps with multiple dependencies. In this scenario, in the C:\Program Files (x86)\Microsoft SDKs\Windows Kits\10\ExtensionSDKs path you will find multiple folders, one for each version. The folder without a specific version number ( Microsoft.VCLibs.Desktop ) refers to the VC 14.0 framework package, while all the others will contains the number inside the folder’s name (like Microsoft.VCLibs.Desktop.120 ). However, here comes the other part that can be confusing: no matter which folder you open, you will always find the app package inside a subfolder called 14.0 , even if you’re installing the VC 12.0 or 11.0 version of the framework package. It’s normal, just ignore it and move on inside the various subfolders: the final AppX inside the Retail folder will have the proper version number in the filename (like Microsoft.VCLibs.x86.12.00.Desktop.appx ).
Important! This procedure is required only in case of testing or manual deployment of your converted application, which means that you’re going to manually install the AppX package on your PC or someone else’s one. In case your app is distributed through the Store, you won’t have to deal with this requirement: the Store, in fact, will take care automatically of solving the dependency and installing the proper version of the library if needed, together with the real application.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.