Error Notifications

[tltaylor76]

I have been using InstallAware for a very complex installation over the last year. I continue to have to write programs to work around the installation in areas that I believe should be handled by the installation. For example, if a file that the installation in trying to copy is open or in use, an error should appear. Instead, it just snuffs any type of error and continues to move forward. I have written a program that I launch before any files are moved to work around this issue. Another issue that I have run into is within the MSI script. For example, if I specify a program to run, and that file does not exist, no error appears. The MSI script just goes to the next line.

These types of issues used to be handled and at least raise an error in the previous installation tools that I have used. Am I missing something here or do I need to set some flag?

I chose InstallAware over the competition because I needed to create custom dialogs (a number of them) and I really liked how easy it was to create custom dialogs and all of the design-time features. I still like the overall feel of InstallAware and I am not giving up yet, but I feel that there are some critical key areas that could be improved that would make your tool the number 1 installation tool out there. The above mentioned problems are a few of the areas that I think would help.

Please let me know if there is some way that I can have InstallAware raise some type of error when an error occurs. The installation throwing an error is FAR better than thinking the installation worked and then having to troubleshoot when support calls start coming in.

[Alex_Ronquillo]

I am going to pass this bug to the R&D team so they can work on fixing it. For current versions there nothing to do, but this shouldn't be present in future version. Thanks for letting us know of the bug.

[tltaylor76]

Thanks for your response and looking into it.

[SteveDude]

This could be good and bad in some situations. I think that's where a pre-flight check would be good. If the error option is added, I would like to the have to option of turning it off or maybe just have it just run in debug mode. Also maybe just creating an error log would be good, that if exists at the end of the install could be displayed to the user or sent directly to tech support.

[tltaylor76]

Well, I agree that there should be an option to turn it off...but I in no way see a down side. If the file does not get installed because it was open, how could that in any way be positive? This is the behavior of every other installation software that I have used in the past and it resolves a LOT of problems. I have already written a "pre-flight" check along with a LOT of other work arounds thus far due to the shortcomings that I have run into and assumed that would be there. But this should be intrinsic to the installation software.

[MichaelNesmith]

Actually, no. Alex's classification of this as a bug is incorrect:

MSIcode commands return their success or error states and write them into the variable provided in the command box. The developer can then read the value of that variable in MSIcode, and take further action as necessary - retry, ignore, abort - and, decide how to present this information to the end-user running the setup - a dialog box, a wizard screen, complete failure, or silent handling. In providing this flexibility, it is the developers responsibility to decide how to handle errors. This does not mean that this is a bug in InstallAware! The Run Program command, for example, returns -1 when the file to run is not found. This is better than having the setup engine always unconditionally throw an error, because the same way you customize your setup dialogs in InstallAware, you can also customize how to handle conditions like these.

[tltaylor76]

Michael,

OK, I will agree with you on the Run Program option and I will add that test. But I do not have control over the writing of the files during the installation. How am I supposed to trap that error? Since this is all done within the Apply Install, how do I know when a file in use is not overwritten?

[tltaylor76]

It is not my desire to spar with you nor to cause any frustrations. The information that I have posted is more from an informative perspective than anything else as I have already found work arounds and have my installation working. I have so much time and energy invested in making this installation work I have no choice but to move forward. But I thought I would post one of the issues that I have had out here to see if there were some type of option.

[MichaelNesmith]

Files are overwritten (or not) by the Windows Installer engine. MSI checks first a file version, and if not available, then the file date. It should overwrite files that are older than the ones you are installing. If that is not happening, you should use logging to find out why.

You can also use Delete Files Recursive to preemptively remove files before Apply Install is called - guaranteeing that your new copies will be installed.

The success/failure state of the Windows Installer phase of setup (the main phase) is returned by the Apply Changes command (Apply Install/Uninstall).

[tltaylor76]

I understand how the versioning of the overwrites works in MSI, and I know that since InstallAware supports only MSI that your hands are tied in some of the internal areas. My point is not how the files are overwritten based on versioning, but rather when a file is in use. I already know what some of these users have been doing. They have been trying to install an update with network shared files files that reside on the server (where the install is taking place) in use. Generally this is because a workstation somewhere is still trying to use the software. And really, this is a mute point because I wrote a workaround that even informs us of their error so support knows about the problem before they call.

But the reason we did not have this issue in the past is because the previous installation software that we used would throw up a retry/cancel message when a file was in use in their MoveComponent method (if using the default script). There are many reasons I moved away from that installation package and went with yours. This is just my input and you can take it however you would like. Thanks for your posts and information.

[SteveDude]

In some of my installs, there are files which are installed, but if there is a time something does't exist or they get clobbered by something in many cases, database, xml and some other support files are regenerated by the program itself. When your user base consists mainly of computer novices, the last thing I want them to see are errors popping up that are not that critical to the installation, but I would rather have error codes and deal with them myself.

You can also check if a file exists, copy it and even run it through the Windows API if required. I usually check for and terminate any current running instance of an app I want to start clean. Never know what user has done or is doing at the time of the install, so you have to prepare for about anything that could affect your install.

I think there is a lot of confusion about Apply Install, it was for me and by all the posts, others too, nothing physical really happens until after Apply Install is called, but there is still an ordered progression that can be followed. Most of the time reordering installation commands in MSICode are the the easy and simple solution.

Some preflight stuff would be nice.