Questions about web-deploy vs. single exe builds
Posted: Tue Sep 29, 2009 7:58 am
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
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