I have an application installer created with Inno Setup that deploys multiple binaries and support files for my application.
When I perform an upgrade installation (e.g. run setup-1.5.exe while version 1.0 is already installed), some of the files from the previous version are frequently in-use, and cannot be replaced until the next reboot. That is fine, Inno handles that case correctly.
However, the logic I really want is: if any files cannot be replaced until the next reboot, then I want all files to be replaced on the next reboot. Otherwise, binaries that are in use are not replaced but some support files might be, leaving the application in an unstable state prior to reboot anyway.
Is there a clean way to accomplish this? I have not been able to find one, short of locking all the support files myself explicitly, which is quite ugly.
Thanks!
Inno can't do this natively. This is why it provide AppMutex and friends to ensure that it's all clear, and if anything is left, it tells the user that they must reboot.
You can then expand on this in your app and refuse to start if a restart replace action is pending.
Related
I'm quite new in the InstallShield stuff, I took this project from a leaving co-worker. However, here's my problem:
I was trying to update a MySQL Server with the setup from 5.7.17 to 5.7.19, which works great most of the times.
I got the feature "MySQL", splitted in "MySQL Data" (includes the performance_schema and mysql database), "MySQL Service" (Service batch files) and "MySQL Binaries" (the files).
For the update, I just changed the binaries by the new one and left the rest. All features are selected and my log tells me, that it installs all files which it hasn't installed by now, leaving the existing files untouched. As this is an update, it seems correct to me.
But sometimes, at the end of the setup process, it uninstalls almost anything of my MySQL Feature again; the databases, the batch files and almost any core file which wasn't changed by the setup before. But why is that and how can I stop my setup from do so?
Kind regards
I think what you're describing is that your file containing the data is not getting updated. Since this type of file cannot be versioned, that's what Windows installer uses to determine whether or not to upgrade the file, you will need to mark the component containing this file to Always Overwrite. Check out the MS docs for the Component table for how to do this with the Attributes field.
You may want to check the conditions on the components in question. Also, check the install sequence to see if it is calling uninstall out of sequence.
I have what might be a simple question and might be....a more complex one. We are preparing to add NSIS to our software, that is, we want people who use our software to be able to create installers using NSIS, but through our software. (We'll be creating functions using NSIS, acknowledging NSIS, etc.) What I am trying to figure out before we get started is how many/what files our customers will be required to have on their hard drive for NSIS to work. So, we just need to know if nsis can be used standalone or if it requires the user to install it into program files, or if it requires a lot of different files in AppData - If we have to bundle a few .dlls, that's not a problem and is expected. Ultimately, if we end up having to bundle NSIS as well, that's fine - We just want to make sure it'll work on other people's computers without telling them to go download it.
MakeNSIS does not read/write from/to the registry or anywhere else and only needs a handful of files for minimal operation.
To build a simple installer you need:
NSIS\MakeNSIS.exe (Just calls Bin\MakeNSIS.exe)
NSIS\Bin\MakeNSIS.exe
NSIS\Stubs\* (If you are only going to use a specific compression mode you only need one, and the uninstaller file if you want uninstall capability)
If you want to use the Modern UI you need its header files, some files from Contrib (Graphics and UI) and system.dll and nsDialogs.dll from the plugin folder.
Everything else is optional but I would recommend that you also bundle:
NSIS\Include
NSIS\Plugins (You can remove stuff you will never need; dialer, splash etc)
NSIS\Contrib (Language files, graphics and UI)
You can find license information here.
You could also just ask the user to install it and enter the path to it in your setup program...
I would just include all of the files. (It's only 5MB or so) NSIS has a zip archive as well as exe installer that includes the necessary files. (Or just zip up the installed directory from exe installer).
From my experience, NSIS does not need to be installed to work. I run a fleet of build servers that build NSIS-based installers, and they each just have the files extracted in a directory. The installer is never run on them. This should mean there are no DLLs to register or things like that.
Just make sure you are following whatever their licensing terms are - I have not reviewed redistribution/bundling of their files in another product, since that is not something I do.
I have a setup that is installing a PDF program. It works perfectly on test machines. When there is other PDF software on the machine, errors pop up because of the large number of shared files that are inuse.
Inno has the /SUPPRESSMSGBOXES option. However I can not seem to configure this to ignore the file copy - it either wants to Abort or Retry. Abort - the setup will fail. Retry - will never succeed because the file is in use.
Does anyone know how to automatically ignore any copy file errors while setting up?
You can use the restartreplace flag for the files that may be in use, it is exactly to suppress those error dialogs.
To quote the documentation of the [Files] section:
restartreplace
When an existing file needs to be replaced, and it is in use (locked) by another running process, Setup will by default display an error message. This flag tells Setup to instead register the file to be replaced the next time the system is restarted (by calling MoveFileEx or by creating an entry in WININIT.INI). When this happens, the user will be prompted to restart their computer at the end of the installation process.
I am using Installshield 2010. I made a basic MSI setup, and I am having a problem with uninstalling.
Uninstalling does not remove all folders.
After a complete install, I then uninstall only to find that there is still a path leftover.
For example, C:\ProgramFiles\CompanyName\Account\User_1234.xml
still remains, while everything else is gone.
The User_1234.xml file is generated by the application, and this file is not normally in the install process. So it makes sense why this file may have some problems getting rid of it (installer side).
At the same time, I would think that it would be removed due to the fact that it is within the CompanyName folder.
Is there any way to specify to get rid of everything inside and including the CompanyName folder?
Thanks for any ideas.
You have a couple problems and I'll address the obvious one first. Yes, Windows Installer default behavior is to not delete user data. This could be files not installed by the installer or files that were modified since the installer modified them. To get the installer to remove them, you must author the RemoveFiles table to teach it which files to remove.
Remove Files Table (Windows Installer)
Now I'll address the less obvious problem. You shouldn't expect your application to be able to write to ProgramFiles at runtime. I don't know what your software does but you should seriously consider this aspect of your application design.
I have an application that uses Inno Setup as its installer.
I am now writing an updater using Inno Setup to apply some updates to various installed locations.
This application can be installed on removable flash drives as a portable app and I would like to be able to roll out the updates across several drives/locations/directories for each drive attached to the PC at once.
Is there a way to get Inno Setup to roll out its contents as an update to each location in an array of locations?
Not directly. One option is to build an install for the files that is designed to be silent.
Then write a second install that compiles that uses the first one. Then you [Code] Section you could call ShellExecute() executing the first installer. You could call the first installer as many times as you wanted.
Although, I suspect this may really creates havok on the Add/Remove Programs.