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.
Related
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’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.
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've got an SDK I'm working on and the previous developer just dropped the DLLs in System32 (Apparently a serious offense: see here)
So assuming I move them out into \Program Files\\SDK (or whatever), how do I make sure that all the apps that needs those DLLs can access them? And to clarify, all apps that access these are doing early (static) binding to the DLLs at compile time so I can't pass the full path to them or anything. They need to be able to find it just given the DLL filename only.
Along the same lines, what about including a particular version of MSVCR80.dll? They all depend on this but I need to make sure they get a specific version (the one I include).
Any ideas?
An SDK is by definition a development kit. It's not a deployment patch...
What this means is that the applications that depend on those assemblies should ship with them and install them into their local \program files.. directories.
The reason for this is let's say you decide to do a breaking change by eliminating an entry point for example. By installing your "SDK", it has the potential to stop older programs from functioning.
You could take a play from the Java handbook and update the PATH environment variable. Whenever a program makes a call to an external assembly it searches along that environment variable until it finds it.
Of course, this could still result in the problem showing up. So your best bet is to just install the SDK into Program Files and let the developers of the products that depend on your toolkit decide whether they want to update their versions or not.
UPDATE
As I'm thinking about this, one last possibility is to GAC your assemblies. In the event you do so, bear in mind that they should be strongly named and properly versioned so as not to step on each other. I don't recommend this route because it hides the actual locations of the assemblies and makes uninstalling a little more difficult then simply hitting delete on your directory.
I can't tell you about your own DLLs, but you should never redistribute Microsoft DLLs alone.
You always have to use Microsoft Redistributable Package.
For example, if your application depends on dll from Dev Studio 2005 SP1, you should redistribute your application with Microsoft Visual Studio 2005 SP1 redistributable. The same applies to 2008. MS provide MSI based installer and Merge Module to include in your own product installer.
You are asking about "DLL Hell", something I had thought every Windows developer was familiar with. The order of search for DLLs is:
the directory the exex that calls them was loaded from
the current directory
various Windows directories (as discussed in your previous question)
directories in the PATH variable
As the Windows directories should be ruled out, that leaves you with three options.
You can put your install path in the search path, which will allow the applications to find them.
Alternatively, you can deploy the DLL's into the same directory as the application that depends on them.
I believe the first is better from an SDK perspective - it'll make development easier. But I think the second is better for when the application gets deployed to end-users, unless you expect there may be many consumers on a single system so the disk and memory footprint of having copies of the DLL are prohibitive.
If you can't install the dlls into the same directory as the exe using them you could append your directory to the PATH environment variable.
You don't say which version of Windows you're using, as the details are slightly different from what I remember.
You could also put your version of MSVCR80.dll in the same folder. However, you'd have to ensure that your folder was before the system one on the path otherwise the linker would pick up the "standard" one first. However, if you adopted the "local" dlls approach then you wouldn't have this problem as Windows searches the local directory first and so will pick up your version of MSVCR80.dll.
Is your version the latest or a previous version? You might be better off getting your app to work with that version or later and then allow the users to update their machines as required. This also illustrates why you should never mess with the dlls in \Windows or \Windows\system32 as, as others have pointed out, you could break other applications by changing the version of this dll.
When I run the program from IDE (VS2008) it works perfectly. When I want to launch it from Windows Commander it doesn't work because it needs DLL that wasn't found.
Used both debug and release builds.
Make sure the Qt DLL's are in your PATH. Two simple solutions are:
Copy Qt's DLL's to your EXE's directory.
Copy Qt's DLL's to %WINDOWS%\System32 (e.g. C:\WINDOWS\System32) (possibly unsafe, especially if you install another versions of Qt system-wide. Also, requires administrative privilages).
You should make sure that the DLLs needed by the executable (probably QT Dlls) are in the PATH or in the same directory as the executable. You can find which dlls are needed by using depends.exe
another solution would be to place path to qt bin subdir in VS tools->options->projects and solutions->VC++ directories.
You could link it statically with all the libraries it needs. Saves messing around with DLLs and stuff. On the down side, you can't update DLLs on your installed PCs to get updated/improved/fixed functionality, and will need to rebuild and redeploy.
So whether or not this is viable depends on what your installation targets are - a few PCs controlled by you, or every man+dog who decides to download your program?
Statically compiling in a library bug (security hole for example) and shipping that to your clients would be very poor form. Doing the same on a secure corporate intranet may make it worth doing just so that you know that each install is running exactly the same.