'Failed to locate Framework DLL' in Centennial

I now have two projects that compile in Xojo, and run fine on Windows 10, build and install and run using InnoSetup, build using DesktopAppConverter, side-load into Windows, but when I run them I get the error ‘Failed to locate Framework DLL’. I have checked the forums but can’t find anything related to Centennial.

Any clues?

You get that after converting the app, right ?

at https://blogs.msdn.microsoft.com/vcblog/2016/07/07/using-visual-c-runtime-in-centennial-project/ there is this little sentence that may explain :

My app is generated with 2015R4.1 so it does not use the C++ redistribuable. But if you built with 2016R3 and had packed the C++ DLLs, it could be the origin of the issue.

The two places where I found some answers are :

  • MSDN UWP Windows Apps forum. Make sure to prefix the subject with [UWP][Desktop Bridge].
    Members are notoriously selfish, and expect Microsoft MVPs to feed them. But yet precisely, MVPs often go out of their way to assist.
  • Stack Overflow. Make sure the subject and tags are as explicit as possible. I got saved from dependencies perdition here.

I am repackaging my apps in order for them to have tiles and icons in the Start menu.

You do that by changing the sample pictures in the Assets folder, within your app PackageFiles folder generated by the Converter.

Then you use MakeAppX to create a new AppX with the changes in. You would do that as well if you needed to change the Manifest.

I wonder if could not put back all the DLLs if that is what is missing, next to the exe. And BTW this enables you to verify the package actually works by launching the Win32 exe there.

[quote=292629:@Michel Bujardet]My app is generated with 2015R4.1 so it does not use the C++ redistribuable. But if you built with 2016R3 and had packed the C++ DLLs, it could be the origin of the issue.

Thank you Michel, when I created my APPX from Xojo 2015r4.1 the error went away! It looks like I’ll be using this version of Xojo for my WAS submissions.

For the time being, my app is not HiDPI, but I do intend to move to it sooner or later. Then it means we’ll have to deal with the redistribuable. But I suspect the DesktopConverter dependencies should care about that. At any rate I will address that when it comes. Not sooner.

I have started a thread in the Microsoft UWP forum this morning, about submission of converted apps. It would be nice to show up there if you can to push our concerns, and add your own. The more will post, the more chances we will have to see them addressed. It is important IMO to show Microsoft there are developers interested in the converter.


BTW, it is not the “Windows App Store”, but simply the “Windows Store”. I believe the correct acronym is “WS”.

I just experimented a little.

I get exactly the same message, even if I add the C runtime DLLs to the packageFiles and repackage the AppX.

Yet, if I double click on the exe within the PackageFiles folder, it runs perfectly.

Looks like you may have found an incompatibility between 2016R3 and the DesktopAppConverter.

Unfortunately, the exact package is not mentioned, so it is impossible to know which one is missing. I am going to post a message in the Msdn UWP forum and cross fingers.


In the meantime, it is definitely 2015R4.1.

You may be able to communicate with a real Microsoft person for your conversion needs. I received an email (maybe even twice) back in August. Here is the relevant part of the email:

[quote]Thank you for your interest in the Desktop Bridge, previously known as “Project Centennial”. Since the initial preview release of the Desktop App Converter at Build 2016, we’ve received a lot of feedback from you and released multiple updates to improve the tooling for the Desktop Bridge.

Today, we’re happy to announce the process of how to work with us to start bringing your existing desktop apps and games to the Windows Store, using the Desktop Bridge. Let us know you are ready to distribute your existing desktop app or game through the Windows Store and we’ll work with you to manage the process of getting your app published. It’s important to note that this is a close collaboration with you and as such, has different timelines than simply publishing your app through the Windows Dev Center.

We look forward to working with you to bring your existing desktop apps and games to the Windows Store. [/quote]

Yes, this is the standard mumbo. They repeat exactly the same sentence on the page where one submits the app to be included in the WS. The link leads to that very page.

Now that I sent my apps through that page, I simply hope it will not fall into oblivion, and that the promise of close collaboration is not one of those empty promises…

According to William Yu, the error message comes from Xojo. He concurs with the possibility that be a runtime DLL missing.

Investigations ongoing …

I am not sure that I read the earlier posts properly and understand them.

For Windows Store apps (which at this point run on windows 10 only), there is no need for any installer to install the VC++ 2015 Runtime or to package them (the DLLs) in the exe folder. The VC++ 2015 Runtime is already installed in Windows 10 by Windows 10 because it is part of Windows 10.

Indeed I am not sure the issue is the VC++ Runtime. But the issue reported by David does occur only with 2016R3 (possibly all 2016), but not with 2015R4.1.

I suspected the converter may have stripped some DLLs, but after verification, it is not at all the case. In the conversion process, the converter creates both an AppX, and a folder called PackageFiles which contains the complete structure of the AppX, and the exe, which opens just fine, meaning it finds the necessary DLL.

I messaged William Yu who takes care of Xojo Windows. He confirmed that is a message from Xojo itself. He thinks it is a runtime, but since the MsgBox does not say which DLL is missing, we are not much advanced.

Is there any way to find out which DLL is missing ?

I reported the error in the msdn UWP forum https://social.msdn.microsoft.com/Forums/en-US/c4a77c88-6d6e-4296-8f61-c0a1cb944ef1/uwpdesktop-converter-failed-to-locate-framework-dll-when-launching-the-converted-app-appx?forum=wpdevelop

Bob Kaplan suggested to look into loader snaps.

Problem is, the issue does not present with the file before they are packaged, only when the app is packaged as an AppX.

We may be on our own for a while. I am not sure Xojo has much interest for the conversion process…

I don’t have a functional Xojo app of my own that I can test. They are still sort of experimental and therefore half-baked. Is there one in the Xojo Example folder that is a good candidate for testing? I can try it out myself with 2016r3 and see what happen. I can build it in one real Windows 10 and test it out on another real Windows 10.

Any Hello World will suffice.

So far David Cox and I have verified the issue consistently with 2016R3.

I unpacked the AppX (it is only a zip file) and looked what is in there, everything is in place, no DLL is stripped.

The only way I get the same error consistently is to remove or rename the Lib folder to non legal name.

This error message box looks like a message box dialog that is thrown by Xojo, not Windows. Xojo should know where the message box text “Failed to locate Framework DLL” is triggered.

William confirmed it is from Xojo.

Ah I missed that. Maybe… maybe it is some dependency that Xojo might have forgotten and that is required by the Desktop Bridge. Some installer builder has the feature to detect dependencies required, probably not available in Inno Setup. I will check mine when I come to that. Give me a bit of time.

I will rule out the VC++ 2015 Runtime.

“C:\Program Files (x86)\Xojo\Xojo 2016r3\Xojo Resources\Frameworks\XojoConsoleFramework32.dll”
“C:\Program Files (x86)\Xojo\Xojo 2016r3\Xojo Resources\Frameworks\XojoConsoleFramework64.dll”
“C:\Program Files (x86)\Xojo\Xojo 2016r3\Xojo Resources\Frameworks\XojoGUIFramework32.dll”
“C:\Program Files (x86)\Xojo\Xojo 2016r3\Xojo Resources\Frameworks\XojoGUIFramework64.dll”

I have no way to try this Centennial, but IMHO it can only be one of the above mentioned 4 files and probably you can forget even the 32 bit version. Then only 2 of them remain as possible cause of the problem.
Is it possible to manually check if these files are copied and if not manually added?

They are present in the AppX (which is the UWP executable bundle format). I will investigate some more later today.

It looks as if in the new application model, the bundle is extracted to memory when the app is installed. It should be possible to look at that folder and see what exactly is there and how it is organized.