I've made a installer via Inno Setup and now I'm need to restart computer after some files were run.
So, i have code:
....
[Files]
....
[Run]
Filename: firstfile
RESTART
Filename: secondfile
....
Is this possible? I have found one example script github, but i cant understand how to use this DetectAndInstallPrerequisites functions.
If someone can advise or provide some simple example, I would be very gratefull
Have a look at the CodePrepareToInstall.iss example script included with Inno. It shows how to arrange for a reboot and have the installation automatically resume afterwards. (You may need to make further changes or save further values if your installation is more complex or prompts for further user input.)
The missing link in that example is that you need to fill in the DetectAndInstallPrerequisites function by using ExtractTemporaryFile to retrieve the appropriate files (as it runs before the main [Files] section is processed) and Exec(ExpandConstant('{tmp}\yourfile.exe'), ...) to actually run the file. If this is a subinstaller you can then check its exit code to determine if a reboot is actually required or not rather than unconditionally requesting a reboot.
Note that this code will be executed again following the reboot, so you also need some way to detect that the subinstall has succeeded and skip trying to run it again. Typically this is done by trying to detect the version of the installed subcomponent.
Related
I have a bash script that works at the moment. It gets an image and JDK 8 from a link and then runs a installer for the JDK 8 to move on to setting up another piece of software.
As I was debugging the script, I kept finding myself having to delete directories and even the java installation because when I introduce a fix and rerun the script, I have to wait for everything to download again and I have to worry about duplicate files messing up my current logic -which can probably be improved, but I'll go to the StackExchange Code Review site later.
At the moment, I would like to know what approaches there are to prevent commands -like downloading the JDK and running the JDK installer script all over again and others- from running again.
What kind of general approaches are out there for cases such as these?
For the JDK download and running the installer, I did think of simply checking for the existing of java on the system and if there is then bash would not not to run those commands.
However, there are other commands I do not want run and I do want to simply check, for example, the existence of certain files to prevent wget-ing them all over again and moving them -causing duplicates. (Should I maybe suck it up and do that anyway as that might be best practice?)
I did also think of perhaps, at each successful command, outputting like a 1 to a text file and mapping each line in that text file to the commands run in the script (like using an if statement to see if that command had a 1 or not in the text file) and if it was a 0, then the script would know only to run that command and never the 1s.
That sounded clunky to me and I am pretty sure that is not a good approach.
I am trying to install a installer developed using InstallShield 2008. While installing after selecting the destination path i am aborting the installation.
When i try to install again by default it is taking the destination path as previously given path which was provided before aborting the installation.
And also it is not allowing me to install in different path.
For Example:
*Step1 : Installation starts
Step2: Destination path as C:\Installer
Step3: Click next and abort installation
Step4: Start the installation again
Step5: Provide Different destination path as C:\Installer1*
Here installation is failed. Because destination is still pointing to Step2
My question is from where Installer is taking the old path.?
Persisted Path: The technicalities appear to be relatively straightforward: the old path is read back either from the registry or from disk each time the setup is launched, and a custom action in the setup's GUI sequence must have persisted the path "somewhere" during the first run (this is erroneous design, see technical comment below). Reading back the value can be done by using AppSearch (built-in MSI feature) or by means of a custom action.
Registry / Disk: As to finding where the value is read from. The easiest would be to just search the registry first for the literal path. Just open regedit.exe and search for the path there. You can also look for the custom action that does the persisting (or the AppSearch or custom action that does the retrieval) and see if it is a script with code you can see - then you should be able to see where it has persisted the path. Use Orca or a similar tool to view the Custom Action table. The custom action can also be compiled and undecipherable. Do you have the setup source? The path can also be persisted to disk, but the registry is most commonly used. Remember to search both HKCU and HKLM.
Involved Debugging: I can't see why you would, but it is also possible to use ProcMon.exe to monitor what registry locations your MSI reads and / or writes to. This is involved debugging and should never be needed for something this simple. Just mentioning it as a technical option. Generally the last resort we have to figure out the strangest problems.
Technical Comment: MSI setups are not supposed to write anything to the registry or disk from the setup's user interface sequence (setup dialogs). All changes should be made from the installation sequence (InstallExecuteSequence) which also generally runs with elevated rights - the user interface normally runs with user rights. This InstallExecuteSequence sequence is kicked off from the last dialog in the GUI sequence, and runs the file copy and system change operations. Control then returns to the GUI sequence to show the setup complete dialogs. It is also possible to run the setup silently, in which case the InstallUISequence never runs and all custom actions inserted there fail to run. Accordingly custom actions should be present in the InstallExecuteSequence as well as the InstallUISequence if they are to run in silent mode. This potential design flaw is a very common silent deployment error which occurs when setups are not designed properly for silent running. Remember that all corporate deployment runs silently. Setup GUI is highly overrated (in my opinion - a "fact" that could change in the future).
It is still possible for an MSI setup to write to the registry or disk from the InstallUISequence by using a custom action to do so. Such a custom action would normally not have access to write to HKLM or to protected parts of the disk - unless the whole setup runs elevated because it was launched from an elevated command prompt (for example), or launched by an admin who elevates it via the UAC prompt.
In other words: this setup is badly designed, but I guess that is clear already.
How can I sync the command line to the setup project installer that it will not proceed until the task of the command line is done?
The installer needs to run BATCH scripts and it needs to log on to the database credentials. But even before logging on to the database, the installer still proceeds and finish the installation process.
You could give a bit more context, but in general the answer is don't use bat files. You could have a custom action VB script that runs the external executeables (if that's what they are) and waits for them to finish. In general, whenever bat files show up during an install it's a red flag that something isn't right in the design. Usernames can be entered in UI dialogs at the front, for example, and passed to custom action programs; also many clients like silent installs where property values (like a username) can be passed on the msiexec command line and again get passed into a custom action, and it all just works - I suspect your install cannot be run silently because you are collecting a user name at the end of the install in a custom action.
I have an installer from a third party. Through trial and error I discovered it was an innosetup installer. When I call it with the /silent flag it installs just fine, until it executes installers for 3 dependencies (direct X is one, for example) which then require user input to cancel. I want to be able to run the installer and have it either install the dependencies silently or not at all. When going through the installer GUI normally it does give me 3 checkboxes at the end on the last page of the wizard (before I would hit the Finish button) that allows me to choose whether or not to install the dependencies. Is there a way of doing this that I don't know about? From my research it seems impossible without knowing the types and components available (and executing the installer with the /help or /? options had no effect) and I will probably need to get a new installer from the third party. The only other option I can think of would be to have some sort of timeout that after a certain period of time of inactivity from the installer I kill the install process (since the files I was interested in had already been installed at that point I think).
Checkboxes on the finish page sound like postinstall [Run] entries. There is no way to influence the selection of these from the command line, except that the original setup author can choose to have a different set of options selected for interactive install vs. silent install. (Or they might have extended the /LOADINF option to work with these, although this is unlikely.)
Given that this is a third-party installer, your best bet is to contact the original vendor and see if you can get them to change the default silent selection, or to add an additional command-line parameter to change the defaults.
Failing that, you could consider using a program such as AutoIt to auto-click the wizard GUI when run non-silently.
(If the things that it's trying to install really are dependencies, though, then you probably should let it install them. And it should be installing those silently too anyway.)
Killing the install process after a specified time seems like an excellent recipe for disaster.
Those are probably [Tasks] within InnoSetup's install, which you may be able to deselect by passing /tasks="" in the command line (along with the /silent). Here is a list of command line options: http://www.jrsoftware.org/ishelp/topic_setupcmdline.htm . Adding /suppressmsgboxes may help also.
It seems it is impossible to do what I wish without knowing more about the structure of their setup. I was however successful in solving my original problem by killing the third party installer after waiting a specified amount of time (which I got from reading this question).
In my InnoSetup I use several file actions in the InstallRun section. If those are executed correctly without problems then a certain temp folder should have been deleted.
If something has gone wrong then the temp folder is still there. In that case I want the setup to be canceled with a messagebox displaying an error message of my choice.
As I have no experience (yet) with Pascal script I kindly ask you to provide me with an example script yo do this.
Thanks in advance!
Addition:
I'll now explain the reason I need this. The scenario is updating an existing version, which is a Windows Service application. Before updating those files I have to uninstall the services first. For this I use my own commandline that's in the installation package. The other new files will be temporary unpacked to a temp folder (subfolder of app folder). After the Windows services are uninstalled the new files are moved from the temp folder to the app folder. If something goes wrong here I want to cancel the setup and show an error message to the user. I can best tell if something has gone wrong by checking if the temp folder is still there.
Assuming that you mean the [Run] section, it is not possible to cancel the installation that late in the process.
Instead, you should look at using PrepareToInstall. In this, all you need to do is to stop and deregister the old service, either directly via API or by invoking a command on the old service EXE as you choose. (Don't forget to handle the case when the service doesn't exist yet, for new installs.)
After this [Files] will replace the files as normal and you can then [Run] or use code (via AfterInstall or CurStepChanged(ssPostInstall), depending on the time you want it to happen) to re-register and start the service.
No need to muck around with temporary folders -- which is good, because that would have caused problems for uninstall as well.