I have an application that I could deploy on other machines (Visual Studio). I added the module QtMultimedia to use the QSound class.
Wanting redeploy my app, the executable indicates me first that I need Qt5Multimedia.dll then Qt5Network.dll (which I have not added in my project).
Now my application doesn't launch, but no error message, I do not understand ...
I did not find much on the internet.
First of all - use dependency walker to list all the dependencies and make sure you have all the required dlls right besides the binary.
Next, make sure you've copied all the required plugins to the appropriate plugin folder besides the binary. In particulary take a look at plugins/audio/qtaudio_windows.dll, I think you might need to deploy it.
Also a good way to check what you app uses is to use process explorer on the machine you have no troubles on to check all the dlls it uses when the app is running.
I finally found !
First I need to go in the folder of my exe
Then use : "windeployqt.exe ." (whithout the quotes).
That add all I need to execute my exe. :)
Related
for a self-built installer I need a way to execute code after closing of an application itself.
Application structure
Main application: The installer is started from it when needed, it closes itself in the process.
Installer: This is also located in the folder of the main application and therefore also accesses all dll files. When an update is available, a zip file is first downloaded and then unpacked into the temp folder. Afterwards, all files are moved from there to the shared application directory.
The problem
The problem is that the updater can only update a few dll files at runtime that are not used by itself, because some are write-protected due to the installer's access.
A solution
Moving the files from the temp folder to the shared application folder must happen after closing the installer. But I don't know how to realize that.
Thanks a lot!
If your problem are the DLLs shared by the installer and main application, then you can do this: Before you run the installer, your main application can copy all the needed DLLs and the installer EXE from your main application folder to a temporary folder and run it from there. Your installer must then only wait until the main application gets closed and then replace all its files in the main folder. And once your update is finished, delete this temporary copy of the installer with its DLLs.
Note that if you want to overwrite files in Program Files folder, your installer will have to be run with elevated privileges. Google for "runas" command... you will need it when starting your installer with QProcess.
But there may be also other problems. If your first installation was with normal installer, it typically creates some entries in registry and also generates list of files for later uninstall. And if your new versions will contain different files than originally installed version, then your subsequent uninstall may malfunction or may leave some files existing on users' computers. And you certainly do not want this.
And yet another potential problem. You may have running several instances of your application. In that case quitting one instance will still leave the other instances running and hence their files will not be replacable by the installer - it will fail.
So as you can see, these are quire serious aspects to take into account.
How I do it in my software and I suggest you try it too? I prepare one installer file (.exe) with InnoSetup (freeware!). This can be used for first installation as well as for automatic updates. Then if I create a new version and put it on the server, the running main application detects it, downloads the new installer and runs this installer (of course it asks the user if it should proceed). The installer then asks for elevated privileges, asks to close the running application (it usually is closed automatically when starting the installer) and overwrites the existing installation. All this is standard functionality built in the installer created by InnoSetup. And correctly updates the uninstall instructions... It took me several days to set up everything to my needs but it works well. The only "drawback" is that it is not completely silent, it shows some dialogs. But this is no real issue for me. Maybe it is better for the users to see what is happening on their computer...
Your question implies Windows. I'll make a suggestion from a Win32 perspective.
In our application, we have a similar issue. Periodically, our application downloads an update executable into a temp folder and then launches it. When the update EXE runs, it makes sure the main application has exited, unpacks the files into the application's installation folder, and then starts the application back up again. It's actually more complicated than that, as it really copies the new files into a different install folder, but I'll save those details unless you really need it.
The problem is that the updater can only update a few dll files at runtime that are not used by itself, because some are write-protected due to the installer's access.
This is the core of your issue. My advice is to have the Installer EXE statically linked to both the VC runtime and the other code its sharing with the application. That is, no DLL dependencies all. If you really need to share code between the installer and the application, but still want the application to use a DLL, you can do this. Have the shared code built as both a DLL (with a stub lib) and also built as a full LIB. May require some minor refactoring to your build or redundantly build the same source files. The Installer code links with the full LIB. The application code links with the stub LIB for the DLL like it does now.
If you are just looking for a way to launch the process, the API you want is CreateProcess.
Also, have you looked at the open source options like Omaha - which is what Google Chrome has used for silent updates?
Moving the files from the temp folder to the shared application folder must happen after closing the installer. But I don't know how to realize that.
The "Windows way" would be to use PendingFileRenameOperations as described in this blog-post and have Windows do the move during the next startup. Of course that implies one more of the annoying "Please reboot to finish the installation" messages.
I have a Qt application, which runs fine when I execute it from Qt Creator. However, on running it by manually clicking the generated exe, I get the following error :
I would understand if it would ask for missing DDLs (which I could then place in the same folder). But how should I proceed to handle this (in general) ?
P.S. It is not giving any line number in my source code which I could try testing this assert for. I tried using the release mode as well, but the same error.
We don't know what the problem with your code is; you'll need to use a debugger to find that out. I think that the pre-built Qt libraries that you download come with debug symbols, but if they don't, you can always build Qt yourself to get them using the -force-debug-info configure option.
You can also use DebugView to see debug output of deployed applications.
However, in general, you should use the windeployqt tool that is included with Qt.
The Qt for Windows - Deployment page has more information about deploying Qt applications to Windows machines, but windeployqt should do everything you need.
My qml files were not getting deployed properly and thus this error (this assert is probably on the variable storing the main qml file name, i.e. it should not be an empty string, which in case of missing main.qml, it was). Placing the qml files at correct paths solved the issue.
Also, as #mitch has pointed out in his answer, use windeployqt to find out the dependencies. Although, I have also realized that it doesn't cover all the dependencies (MSVC runtimes for example and other compiler related files sometimes). In that case run the dependency walker and place the missing files manually along with the exe.
I tried to follow this link to deploy application for Windows, but I don't have the file configure and I am unable to run the command.
Any help ?
Skip the configure step. What you need is the windeployqt utility.
Afterwards you may need to remove some libraries your project doesn't use. For my projects, windeployqt insists to deploy a huge openglsw.dll (or something like that), even though I don't need it.
I also recommend simply copying the MSVC libraries into your distribution rather than installing from the supplied installer package. Just make sure you got all of them, the right version and for the right architecture.
If you use the Qt Network module, you may want to also deploy the OpenSSL binaries - you'll need them if you want to access HTTPS resources.
And my last advice - use Inno Setup for installer. It is well documented, very well written, very easy to use and produces no junk.
P. S. You could use one of my open source projects for reference, I have a script to copy all the necessary files into one folder and pack it into an installer using Inno Setup. I try to keep the scripts as simple and short as possible, no junk there.
I developed a Qt application in MacBook (El-Capitan 10.11.2) and it is ready now to be released.
What i want now, is to create the standalone executable file for both Mac and Windows OS.
But I don't know how !
I found this link but I am unable to follow it is guidance, it looks different from what my system is showing me.
If you have any idea, please help me.
Thank you
Well, to compile an application for windows, you will need a windows machine (or at least a virtual machine). You can't compile for windows on mac.
Regarding the "standalone": The easy way is to deploy your application together with all the required dlls/frameworks and ship them as one "package". To to this, there are the tools windeployqt and macdeployqt. However, those will not be "single file" applications, but rather a collection of files.
If you want to have one single file, you will have to build Qt statically! You can to this, but you will have to do it on your own. And if you do, please notice that the LGPL-license (the one for the free version of Qt) requires you to make the source-code of your program public! That's not the case if you just link to the dynamic libraries.
EDIT:
Deployment
Deployment can be really hard, because you have to do it differently for each platform. Most times you will have 3 steps
Dependency resolving: In this step, you collect all the exectuables/lirabries/translations/... your application requires and collect them somewhere they can find each other. For windows and mac, this can be done using the tools I mentioned above.
Installation: Here you will have to create some kind of "installer". The easiest way is to create a zip-file that contains everyhing you need. But if you want to have a "nice" installation, you will have to create proper "installers" for each platform. (One of many possibilities is the Qt Installer Framework. Best thing about it: It's cross platform.)
Distribution: Distribution is how to get your program to the user. On Mac, you will have the App-Store, for windows you don't. Best way is to provide the download on a website created for this (like sourceforge, github, ...)
I can help you with the first step, but for the second step you will have to research the possibilities and decide for a way to do it.
Dependencies
Resolving the dependencies can be done by either building Qt statically (this way you will have only one single file, but gain additional work because you will have to compile Qt) or using the dynamic build. For the dynamic build, Qt will help you to resolve the dependencies:
macdeployqt is rather easy to use. Compile your app in release mode and call <qt_install_dir>/bin/macdeployqt <path_to_your_bundle>/<bundle>.app. After thats done, all Qt libraries are stored inside the <bundle>.app folder.
For windeployqt is basically the same: <qt_install_dir>\bin\windeployqt --release <path_to_your_build>\<application>.exe. All dependencies will be inside the build folder. (Hint: copy the <application>.exe in an empty directoy and run windeployqt on that path instead. This way you get rid of all the build-files).
Regarding the static build: Just google it, you will find hundreds of explanations for any platform. But unless you have no other choice but to use one single file (for whatever reason) it would recommend you to use dynamic builds. And regarding the user experience: On mac, they won't notice a difference, since in both cases everything will be hidden inside the app bundle. On windows, it's normal to have multiple files, so no one will bother. (And if you create an installer for windows, just make sure to add a desktop shortcut. This way the user will to have "a single file" to click.)
I’m currently logged onto a machine and my current problem involves a custom build step that has trouble copying a .dll to the Bin directory because Windows says it cannot access the file because it’s currently being used by another process.
I’m able to reproduce this on several other projects. The sequence of events is that I build a release successfully, do some test, checkout another SHA when doing a git bisect, and attempt to build a release from that SHA without doing a git clean -xfd (intentionally, because I’m trying to cache as much reusable data as possible). The weird thing is that I tried to use Process Explorer (procexp) and tasklist /m <locked_dll.dll> to search for whatever is holding onto this dll, and am unable to find anything holding onto the dll. I’m on a non-admin account, and I’m not sure if that is causing Windows to hide certain processes from me. Rebooting the machine helps, but that’s not an acceptable solution since I’m trying to automate things. I’m able to delete the .dll, and when I try to build the project in VS, it’ll complain that it still can’t access the dll when trying to copy it over to the Bin folder. Any ideas? I’m going to keep researching the issue, but as of right now, I’m sort of stumped.
EDIT:
This seems to be a duplicate question (Error: Cannot access file bin/Debug/... because it is being used by another process), but I'll leave this open to see if anyone has found anything new related to the topic.
I've seen this problem in VS 2010 with a large .Net solution with multiple projects in it. Every case I've seen so far pertains to have one project with dependency DLLs that another project also uses, and that other project also uses the first project as a reference, and also uses the same dependency DLLs that happen to be a different version from the first project.
To describe it a different way:
Project A depends on v1 of DLL A
Project B depends on project A and v2 of DLL A
Both project A and B are in the same solution
The solution is to use the same version of DLL A. I usually run into this when upgrading to a new version of SQLite, and I forget to update the dependency in all of my projects.
After talking with a few coworkers, I found the solution to my problem. procexp and tasklist did not see which process was locking the dll because there was no process locking the dll on that particular machine.
I have a hardware configuration where machine A (a host PC) is connected to machine B (acts as a client that retrieves instructions from machine A) using a network switch. machine B runs the same binaries that link to the same dll's. Thus, obviously, running procexp or tasklist on machine A will not see anything locking the dll's because machine B is the culprit.