Hello,
The installer we built at my company has for a long time been built using the single self-installing exe build type, and it has been working fine for us. Very recently however we stopped being able to uninstall after installation. Trying to uninstall would give us an error message that the original installer sources could not be found.
After reading some other threads on this forum I saw that the single exe installer does not cache itself on the user's drive during installation and that a web deploy build with only one unnamed block could be used instead. However, if the single exe installer does not cache itself, why did uninstallation ever work, and why might it have stopped working?
Switching to the web deploy buildtype fixes the uninstallation problem, but brings a new problem with it. When starting the installer, it goes through three phases that I can see: first, the compressed exe extracts itself. Second, the installer is started. Then, the installer seems to uncompress itself *again* into a different directory on the user's drive (under c:\\documents and settings\\all users\\application data\\{random guid}). This last extraction step is the problem, because there is no dialog to report progress to the user and it takes quite a bit of time (our installer is roughly 400 megs uncompressed, and 200 megs using the lightest compression setting which is what we use). It looks to the user as if the installer has failed to start while it is unpacking itself this third time, and they are likely to try to start itself again, which will just compound the problem.
I'm trying to understand a few things, then, and would very much appreciate whatever help can be offered:
1. Is the single exe installer supposed to be able to uninstall without asking the user to find the sources? Why might this have been working until now and then stopped?
2. Is there some way to get the web deploy installer to give the user feedback when it is caching itself during this third extraction step?
3. Is there some other alternative to fixing this problem that I haven't seen yet?
Thanks very much
Zvi
Questions about web-deploy vs. single exe builds
No, we haven't recently upgraded. I'm using Installaware 8.
I'm trying to track down exactly which change I made that caused it to stop being able to uninstall in the first place. I think it has something to do with adding/moving "define file bag" commands, but I can't imagine why doing that would cause the single exe installer to not be able to uninstall.
I'm trying to track down exactly which change I made that caused it to stop being able to uninstall in the first place. I think it has something to do with adding/moving "define file bag" commands, but I can't imagine why doing that would cause the single exe installer to not be able to uninstall.
I haven't been able to figure out this problem yet, but I ended up going back to an earlier version of my project and being more careful about the changes I make. I discovered that moving some file bag definition commands in my installer script causes the installer to no longer be able to uninstall from the Add/Remove list. I'm not sure why this is the case, but as long as I don't move those file bag commands, it should be fine.
This seems very fragile, though. I'm experimenting with InstallAware 9 now to add the caching option to the single-exe build, to re-enable the uninstall. However, doing this will once again cause the installer to take a long time doing this caching, and at this time there is no progress bar of any kind displayed to the user.
Does any one know how to work around this delay? It seems silly that a large enough installer doing this self-caching will cause the installer to dissapear for such a long time with no notification at all.
This seems very fragile, though. I'm experimenting with InstallAware 9 now to add the caching option to the single-exe build, to re-enable the uninstall. However, doing this will once again cause the installer to take a long time doing this caching, and at this time there is no progress bar of any kind displayed to the user.
Does any one know how to work around this delay? It seems silly that a large enough installer doing this self-caching will cause the installer to dissapear for such a long time with no notification at all.

