Trouble deploying application
I've been having trouble getting my .exe to work on computers without Visual Studio and the Windows SDK installed. I created my GUI app in Qt Creator. If I just build the .exe and stick it in a flash drive alongside the neccessary Qt .dlls, it runs fine on my other computer that has VS and the Windows SDK installed. However, it's still relying on msvcr100d.dll. So I bring the code into Visual Studio 2010 Express, switch to Release mode, change the Additional Dependencies from QtCored4.lib to QtCore4.lib and so forth. But when I try to run the resulting .exe, I get a popup saying:
QWidget: Must construct a QApplication before a QPaintDevice
(Press retry to debug the application)[/code]
I don't get this when I run the executable resulting from compiling in Debug mode.
What's going on?
If you build a binary you are going to deploy, you should link against the "Release" version of the Qt libraries (QtCore4.lib instead of QtCored4.lib, and so on). But that's not sufficient. You must also build your main program (the "EXE" file) with "Release" configuration, so it will use the "Release" version of the C++ Runtime rather than the "Debug" C++ Runtime. Also, in "Release" mode, the compiler will use more optimizations for your code.
If in doubt, use "Dependency Walker":http://www.dependencywalker.com/ to check all dependencies of your application !!!
Anyway, the error message indicates that you are creating a GUI widget before you have created the QApplication instance. You should check your code again to make sure you create the QApplication object first...
That's the thing - the version I build in Release configuration, linked against the release versions of the Qt libraries, doesn't run, even though I don't get any compile or link errors. The same exact code works fine if I build in Debug configuration, linked against Debug versions of the Qt libraries. I don't understand why that error is coming up if all the code I wrote is staying the same.
Maybe there are some #ifdef's in your code that make the Non-Debug code different? Or it's just that the Debug Qt libraries will handle the problem that always exists in your code more gracefully, while the Release version fails right away? Anyway, it's time to step through your code and see where exactly the problem occurs! There must be a place (code path) where you create some Qt Widget object before you create the QApplication object. Once you found out where exactly that happens, it should be easier to track down why that code path is only entered in the Non-Debug build. Or maybe it will turn out you always have the problem (but just don't always notice).
I guess that is as much advice as you can get, without posting a short(!) sample code that reproduces the issue.
Hi, I think you must also build your main program (the “exe” file) with “Release” configuration.
I had been building in "Release" configuration.
Thanks for the link to Dependency Walker, Mulder, that thing was really helpful. I think I've resolved the problem, maybe - at least, that error message isn't showing anymore and the exe runs fine on computers that have Visual Studio installed. Dependency Walker tells me the release version is relying on the plain C++ 2010 redistributable, rather than the debug version, which is good.
However, it still doesn't work on computers without the Windows SDK installed. This time there's no error message at all. I start the exe and nothing happens. If I open Task Manager and look at the Processes tab, I see my .exe appear briefly, then disappear after a few seconds. This happens even if I explicitly run it with Admin priviledges. It's like the program is closing itself.
Why would it be doing that?
Perhaps related, Dependency Walker shows some errors when it's looking at my .exe:
[code]Error: At least one module has an unresolved import due to a missing export function in an implicitly dependent module.
Error: Modules with different CPU types were found.
Warning: At least one delay-load dependency module was not found.
Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module.[/code]