Recently I needed to create a deployment package for my Qt-QML application. This process is quite tedious, as you need to manually find and copy dependencies. As described in (official?) Qt Wiki:
Copy the following into C:\Deployment\
- The release version of MyApp.exe
- All the .dll files from C:\Qt\5.2.1\mingw48_32\bin\
- All the folders from C:\Qt\5.2.1\mingw48_32\plugins\ (If you used QML)
- All the folders from C:\Qt\5.2.1\mingw48_32\qml\
Do the deletion steps below in C:\Deployment\ and all of its subdirectories.
After each deletion, launch C:\Deployment\MyApp.exe and test it.
If it stops working, restore the files you just deleted.
- Launch MyApp.exe. While it is running, try to delete all DLLs.
The DLLs that aren't used will go to the recycle bin,
leaving behind only the DLLs that you need.
(This trick doesn't work for .qml and qmldir files, however).
- (If you used QML) Delete a few .qml files and try relaunching MyApp.exe.
Repeat until you try all .qml files.
- (If you used QML) Delete qmldir files from the folders that have no more DLLs or .qml files
For any modern tool such procedure looks completely ridiculous. Yes, I know about windeployqt.exe, but it doesn't find all the .dll dependencies and does not help at all with .qml dependencies.
Is anyone aware of more practical approaches to this problem, how do people deal with this in big projects? Are there any tools that could help?
Are Qt developers planning to do something about it?
For windeployqt there is the option --qmldir.
windeployqt --qmldir f:\myApp\sources f:\build-myApp\myApp.exe
So it checks also the import and fetches the qml dlls too.
All of this is described in the linked article
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'm having a difficult problem to solve. I'm having two Qt-based applications, first one is in the main folder and the second one is located in it's subdirectory (yes, I'm forced to have it this way). The issue I'm facing is that I have to deliver 5 exact the same DLL's files for each application. I wouldn't have problem with that, if they wouldn't weight so much (10 DLL files = 60~ MB). Which is, definately too much.
On my debug build I am able to set the PATH variable within Visual Studio settings, and I will be not able to do so on production machines.
Is there any way I could set one of those application to rely on DLL files located in subdirectory?
I don't know what kind of an installer you're using, but the dlls should be stored only once in the archive, and the files should be hard linked on installation. So it's a non-issue unless your installer is broken or the install script is.
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. :)
I have deleted my application target and now all my Build option are gone. I cannot run my project because I am missing a target. How can I regenerate it?
You have two options.
The first is DarkDust's suggestion: restore from a backup or an SCM repository if you have them. If you have neither, you must admit you were begging for trouble.
The second is unfortunate but comes with a message of hope. Recreate the target from scratch. Select File > New > New Target from the main menu and select the appropriate target type (a Cocoa Mac OS X application, doc-based, or whatever). With the new target selected, click the Build Phases tab, expand the Compile Sources phase, and drag all your implementation files - .m (and .c and .mm if you have them) - into the list so they're compiled as part of this target. Expand the Link Binary with Libraries phase and add in any frameworks you use. Expand the Copy Bundle Resources phase and drag in your resources (including xibs, credits, InfoPlist.strings, your app icon, etc.). Don't forget to recreate any Copy Files build phases you might have set up manually (if you did, you'll already know how). That should do it. The message of hope I mentioned is that you're now familiar with what a target is and all it needs to build your product. It's actually a lot simpler than it appears.
If restoring from a backup or a repository is not an option, and your bundle has many resources, I'd recommend starting a new XCode project from scratch and importing the source files and resources into it.
Create a new Xcode project of the same type and info as your project.
Delete this new project's ViewController and AppDelegate source files, copy your source files into the new project's folder, then import them into the Xcode project.
Add any frameworks you've used.
Import the resources (images, sounds, plists, etc) into the project.
It might take longer than recreating a target and adding things to it, but you're less likely to make mistakes along the way, and you'll ensure that everything is properly added to the target.
If you have version control then the following method works. I used another method to revert my changes if there are not much, executing "Git checkout ." on terminal. Changes will be reverted and Your target will be restored.
I have compiled my Qt application and now have the following question - now my built project requires QtCore4.dll and QtGui4.dll to be located at the same folder where the .exe file is. (I built my project using MSVS2008 with Qt addon)
Q:
Is there any way to combine my final application with these .dll files so that they make one large .exe-file? (I simply don't want to have another bunch of dll files with my release - app)
Thank you.
You need to build and link to Qt statically.
Edit: Here's an updated link to at least similar information.
Bundle them into a self-extracting .exe (e.g. using 7zip) which extracts all files to a temporary directory, runs the program, then deletes the files after the program exits.
This will be easier, less time consuming and less legally constraining than statically linking Qt as previously suggested.
Of course you could statically link someway. But the point of using DLL should be to make program smaller (both on disk and in memory, if other apps are using Qt libs of course)... DLL such as those should be systemwide so that other apps needing them can use them. Basically you have to say to people wanting your program to work, to install the Qt framework.
Deploying the other way is explained here, read the part related to Static Linking.