I am using Installshield, and have had success in launching my exe install files (such as KLite) after all my files have transferred to their target destination.
My question is this:
I am currently able to launch all the install exe's necessary, but they all launch at the same time, which can be rather annoying and cluttering. I am using a "Custom Action" to launch each executable. I am trying different "In-Script Execution" properties to no avail. My "Return Processing" is set to Asynchronous(Waits for exit code), yet it still is giving me problems.
I'd like to have each one execute once the previous is completed.
Anyone have experience in this? It has to be possible...
Thanks,
-Kyle
You want Sync not ASync. BTW, I don't reccomend EXE CA's except in the rarest of situations. Primarily because they are out of process with very limited ability to report back success and 0 ability to write back to the Windows Installer Log and have very unprofessional flashing of DOS CMD windows.
Always try to use C++ / C# custom actions instead.
Also be sure to read the following:
Integration Hurdles for EXE Custom Actions
http://blogs.msdn.com/b/windows_installer_team/archive/2007/10/20/integration-hurdles-for-exe-custom-actions.aspx
If you must use an EXE be sure to use something like WiX QuiteCA ( you can wrap this up into a WiX merge module and consume it with your InstallShield Basic MSI project ) to help shield you from these problems and get improved logging.
Related
I have an installer whose initial installation will be done by a human, but updates have to be done automagically.
Handling installer failure is a problem. I have to plan for the installer to fail: I use the <RollbackBoundary/> element in the Bootstrapper to get to a good state, and then I use both the WiX log and a log of my own devising to document the failure.
However, that's not good enough.
There's a program (let's call it X.exe). If-and-when the installer fails, I need to roll back to the state that the installer was in before the installer started and:
Restart X.exe or
Restart the target machine so that X.exe can start (I install X.exe into the startup folder of the target computer; this is also what I do for a successful install -- restart the target machine).
Deal with the problem in some as-yet unforeseen way.
Is there anything besides Logging that WiX can do for a installer failure? Is there a condition that is set that I could catch, or... anything?
I learned WiX through the fantastic book WiX 3.6: A Developer's Guide to Windows Installer XML (by Nick Ramirez), but I can't find anything to solve my problem there, nor can I find it on the interwebs.
I'm hoping there's something obvious I missed. Does anyone know how to deal with installer failure besides logging them and calling it a day?
Based on the lack of answers and lack of finding the answer to my question in existing resources, I realize that I'm simply asking Windows Installer to do too much.
I was hoping that there would be a way to do something like:
if (installation fails)
{
do something (besides rollback and logging)
}
I wonder if other installation programs provide functionality like this? Or if there's some other way to get a target machine to do something if the installer fails?
There is, in theory, but the whole area of rollback is fraught with caveats. Consider the "installation failed" dialog box and how it differs from a success case: you could run a custom action on that dialog box. But that's only if there's UI. So maybe do things from the rollback action. But what if Rollbacks are disabled? Your only mildly robust solution will be outside of the Windows Installer package.
So in your X.exe, make sure to capture the return code so you can identify a success, a cancelation, a failure, and various reboot required states. If it's a failure, then consider applying your external fix (your reboot, or whatever). If you didn't write X.exe, consider doing so, or writing something that will call X.exe.
But really PhilDW's comment gets to the core of it: rebooting on failure is not an expected behavior for an application installer. (Reboots by application installers in general are advised against.)
I'm developing a windows application (using vb.net) that can install various versions of runtimes like vc++, Direct X, .net frameworks etc on a PC. My program must be able to to run the runtime installers (msi & exe) one at a time in the background and do the following:
1.Check weather the runtime is already (previously) installed or not.
2.Show the installation progress in a progress bar in the main form of my program.
3.And at last get the return code (exit code) from the installer to indicate weather the installation was successful or not.
What are the codes required to perform the above tasks?
Also I want to know what are all the possible return codes(values) an installer can return.
All of those redistributables might have different command line options, so it's not likely to be one answer for everything.
It's not clear how you can get the installation progress. It's almost certainly impossible or very difficult. You're asking how you can run a program that will "steal" the output of some other program, and in many cases that will be Windows Installer. If I had a program that fired off a Windows Form program, then you're asking "how can I get the content of that program and steal the output messages". That's not an install question, it's a Windows messaging/windows message loop question.
The detection methods used by those setups are coded internally (or configured as internal data), so you're also asking how the code in all those programs detects that the dependency isn't installed (on multiple OS versions and 32-bit and 64-bit), and some of that might be available on the web but it's unlikely that it is readily available for every redistributable.
You might also have an issue with EULAs. Some redistributables need a EULA to be accepted and might not install unless it's accepted, or some may have a command line option that includes something like (just an example) ACCEPTEULA=1.
Basically you should:
Find the command line options available for all those redistributables to see if they have an option that displays only progress, then let them show that.
Similarly, see if they have documentation that tells you if the exit code means success or not.
Don't bother trying to find all the detection methods for everything - just run the redist, and if the target is already installed it won't do anything.
Finally, you are re-inventing the wheel. WiX, the Bootstrap Manifest Generator, InstallShield, Advanced Installer (and so on) all provide bootstrapper programs that already do this as prerequisites for installing software. Nobody writes code to do this any more because there are existing solutions.
https://msdn.microsoft.com/en-us/library/windows/desktop/aa376931(v=vs.85).aspx
1638 for already installed. 0 for successful installation. Yet mind 3010 which stands for success but pending reboot.
About showing progress in parent window .. this may be not a trivial task. Hopefully someone else can give you a hand with that.
I'm writing an installer for an application. Most of the installer is done and working, but I have on more step outstanding. I need some way to add a setup window to the installer, that will take user input like server address and port, etc. and write these to the relevant files for system start-up. This preferably done through a GUI of sorts inside the installer.
I've tried creating an executable file that runs after installation, but this does not always execute on different systems.
Is there a way to add a GUI to the installer itself that executes after the directory structures and files have been put into place?
Thanks in advance.
In general you should seriously consider doing this as a standalone app that runs when the app first runs and needs configuring. Then it's a program that runs in a user context and can be tested and debugged in the normal way. At least consider what the user is going to do if they want to change the server address or the port - will they need to uninstall your app and reinstall it just to change the server details or the port?
The GUI may not run correctly when started from the install for a number of reasons. It may be initiated with the system account if it's a deferred CA. It wasn't started from the interactive user shell, so it probably won't have any idea of a working directory. It's being run from an msiexec.exe process running in the system directory and maybe with a system account - that's not really the place to be doing your GUI configuration.
I assume you're using WiX, it doesn't say so in your question but it's tagged with WiX.
I would have a read of http://wix.tramontana.co.hu/tutorial/user-interface-revisited (or http://www.dizzymonkeydesign.com/blog/misc/adding-and-customizing-dlgs-in-wix-3/ has a relatively easy to read example), you can add or edit any of the dialogue boxes in the installer, you'll need to download the source to get at the built in dialog, and it does require some "play" to get everything quite right but worth it to get a professional looking installer.
I have a working WIX Bootstrapper that does install the software I need it to install. However On Windows 8 At least, there is a 16 minute period where it appears to do nothing. Looking at TaskManager, I see no processes taking resources from the Bootstrapper (that I can tell). For some reason about 15 minutes into it it will just finish the install:
[0E6C:0E90][2014-01-24T13:49:45]i299: Plan complete, result: 0x0
[0E6C:0E90][2014-01-24T13:49:45]i300: Apply begin
[0E04:0DD8][2014-01-24T14:05:35]i360: Creating a system restore point.
[0E04:0DD8][2014-01-24T14:05:50]i361: Created a system restore point.
Any ideas as to why this is taking so long, after the log says "Apply begin"?
Note: Behavior does not happen on XP or Vista, Or 7. I think it has something to do with "pausing" Windows updates during installs. Does anybody know anything about that?
Thanks.
This sounds like a timeout of some sort. I assume there are multiple MSI files, and some of them may be tagged with a launch condition (look in the LaunchCondition table) which disallows installation on Windows 8? Maybe worth a check at least. Try launching each MSI manually in sequence and see if you receive any error messages. There may also be missing runtimes such as .NET, C++, Crystal Reports or similar. Often the MSI will display an appropriate error message to tell you what is wrong.
In case you find nothing when launching each MSI, you should make verbose log files for all of them so there is something to work with for debugging. If you are unfamiliar with msiexec.exe (Windows Installer Command Line Interface), you can use the tool described in this thread: installation using msi.exec open help options every time . It should be easy to enable verbose logging using that tool.
Also check this thread: How to skip a bootstrapper or ignore fail in Windows 8?
And the documentation might be useful: http://wixtoolset.org/documentation/manual/v3/howtos/redistributables_and_install_checks/
I never could find a parameter or condition in my installer that would cause this. However the effect went away when I used insignia to sign my wix projects (MSIs and a bootstraper). Prior to that I had been using the signtool by itself to do the signing.
I'm developing an "installation" like cocoa application wich needs to take care of some http request, some file system reading, copying files to /usr/share, set up cron (not launchd) and ask some information to user.
I discarded PackageMaker since I need more flexibility.
Currently everything is going well, but on my last installation step, I need to:
Delete my previously installed application folder (if exists). It's always the same path: /usr/share/MY_APP
Create again the application folder at: /usr/share/MY_APP
Copy application files to /usr/share/MY_APP
Update a cron job
It's very important that /usr/share/MY_APP keeps protected with administrative privileges, so a regular shouldn't delete it.
What would be the best approach to implement those steps?
BTW, I'm using Xcode 3.2.
Thanks a lot!
Carlos.
Between the preflight script, the postflight script, and perhaps an Installer plug-in for the custom UI, I see no reason why you can't do all of this in PackageMaker.
Note: “Installer plug-in” is a little misleading. The user does not have to install the plug-in somewhere as a separate step; you include the plug-in inside your package, and Installer will use it from there.
The relevant document is a ReadMe file in a sample code project. There's also an Installer plug-in project template in Xcode since 2.0.
Also, an Installer plug-in won't get used if the user does a command-line installation. Of course, they can't install from the command line at all (which includes remote installation onto an office or lab full of machines) if you write your own custom installer.
By the way: Why /usr/share? What are you putting there? There may be a better way to do what you're really trying to accomplish.