Jump to content


This is a ready-only archive of the InstallSite Forum. You cannot post any new content here. / Dies ist ein Archiv des InstallSite Forums. Hier können keine neuen Beiträge veröffentlicht werden.
Photo

(Maintenance Mode) Repair from Add/Remove Programs


8 replies to this topic

meemax

meemax
  • Members
  • 10 posts

Posted 12 May 2005 - 11:33

Hello everybody,

I've been on this thing for like half a day and I haven't done anything else. I'm at my wits end! Hope you can help me on this.

The add/remove program provokes the Maintenance Mode of my installer when clicking the [change/remove] button of the application. Choosing to repair does not cause any problem at all.

But choosing to repair again, brings out a dialog asking to provide the location of the next disk? I know this is a bug but I can't find any solution in the internet (or I haven't looked hard enough).

Please help me on this.

Taco Bell

Taco Bell

    IS6 Expert

  • Moderators
  • 1,281 posts

Posted 13 May 2005 - 01:57

Hmm, well I don't actually use Maintenance mode in my setups, but I'll try to help you out anyway.

Now, first off, let me make sure I understand what you're saying. So you go to Add/Remove Programs, click Change/Remove for your entry, go through a Repair successfully. Then after that's done you repeat this process, and that's when get this unforeseen prompt.

If that's the case, then exactly which version of InstallShield Professional 6 are you using, and on which OS & service pack are you experiencing this issue.

Also, I would ask that you compare the contents of PROGRAMFILES\InstallShield Installation Information\PRODUCT_GUID (see the help fille and/or the Basic FAQ for more info. on PRODUCT_GUID) before the first repair versus after the first repair, and let us know the results.

Edited by Taco Bell, 13 May 2005 - 18:24.

user posted image

meemax

meemax
  • Members
  • 10 posts

Posted 13 May 2005 - 06:29

The versions are InstallShield 6.2 and PackageForTheWeb 3.

I would like to correct what I just said yesterday. After many tests, I found out that when I install using the packaged Installer (i.e. using PackageForTheWeb 3):

1. The Repair operation in the Control Panel fails almost all the time. The "Setup Needs The Next Disk" dialog is displayed. In addition is the message "Please insert disk 2 that contains the file Setup.ini"

2. However when I use the Repair Operation through the packaged installer(i.e. not through the Control Panel), Repair succeeds all the time.

On the other hand, if I install using a non-packaged installer (not using PackageForTheWeb), the Repair operation succeeds all the time, whether I Repair through the Control Panel or through the said installer.

I found out that in both packaged and unpackaged installers, the number of files
were the same, namely:
data1.cab
data1.hdr
layout.bin
Setup.exe
Setup.ilg
Setup.ini
Setup.inx

Other findings:

In packaged installations, when doing the Repair/Remove operation through the Control Panel , there is no temporary file created in the directory C:\Documents and Settings\ensomor\Local Settings\Temp.

However (still in packaged installations), when doing the Repair/Remove operation using the packaged installer, a temporary file is created in the said directory (i.e. filename of the form pft*~tmp).

Thanks in advance, I could really use some help:D

Edited by meemax, 13 May 2005 - 06:36.


Taco Bell

Taco Bell

    IS6 Expert

  • Moderators
  • 1,281 posts

Posted 13 May 2005 - 18:24

Are you sure your InstallShield isn't version 6.12 instead of 6.2? 'cause I've never heard of the latter update.

Also, even not having dealt with Maintenance mode that much, I could see PFTW having an effect on its operation.

Therefore, my first suggestion would be to try and switch the default media for your IS project from say CD-ROM to Single Disk Image. This will essentially have the same effect as using PackageForTheWeb, but avoid the additional of step of packaging it yourself.

Now, in those cases where the Repair doesn't ask for the next disk and automatically succeeds is because it can locate the additional data files such as data2.cab.

Unfortunately, I'm not familiar with where IS is automatically putting these in the unpackaged situation. I would have expected it to reside in that same InstallShield Installation Information subdirectory, but evidently that's not the case.

'cause my initial suggestion, before reading your original post, was to have you modify your InstallScript such that you copy such subsequent CAB files from the built-in system variable of SOURCEDIR to the previously mentioned PRODUCT_GUID location.

This approach would probably still work, but it's kind of hack and there's probably a better way to do it based on your test results.

Just to further clarify things though, would you please post the registry contents for your corresponding Add/Remove Program entry. That being the following:

HKLM\Windows\CurrentVersion\Uninstall\<ProductGUID>
user posted image

meemax

meemax
  • Members
  • 10 posts

Posted 17 May 2005 - 07:31

Actually, the Splash Screen whenever I open InstallShield displays "Standard Edition 6.2", but the "About" dialog displays "Standard Edition version 6.22".

I've also tried "Single Disk Image" as you suggested, and the result is still the same as packaging it myself. I also found out that the problem is the same for Modify and Repair.

I also tried your other suggestion by copying data2.cab in the PRODUCT_GUID location and found out that the problem still holds even after copying.

I found out that in packaged installations, the very same temporary directory created by PFTW during installation (i.e. pft11A~tmp) is the directory Installshield looks for upon Modify/Repair. (i.e. pft11A~tmp\Disk1).

And so when I ran PFTW and used the "Copy to folder (user can override location)", Modify/Repair operations now work successfully everytime. (but of course, this measure can't be used as solution as the (1)temporary folder never gets deleted and (2)an unnecessary window pops up asking the user where to place the temporary files).

HKLM\Windows\CurrentVersion\Uninstall\<ProductGUID> contents:

(Default) - (value not set)

DisplayIcon - <some file>

DisplayName - ????? ??? Device Utilities (? is some character)

LogFile - C:\Program Files\InstallShield Installation Information\{7990A1BF-AE09-4AD2-98B2-CA4E072535A0}\setup.ilg

UninstallString - RunDll32 C:\PROGRA~1\COMMON~1\INSTAL~1\engine\6\INTEL3~1\Ctor.dll,LaunchSetup "C:\Program Files\InstallShield Installation Information\{7990A1BF-AE09-4AD2-98B2-CA4E072535A0}\Setup.exe"

Edited by meemax, 17 May 2005 - 07:53.


Taco Bell

Taco Bell

    IS6 Expert

  • Moderators
  • 1,281 posts

Posted 17 May 2005 - 14:17

First off, an InstallShield version of 6.2 is entirely possible and certainly okay, so disregard my earlier comments. I was mixing up my version numbers, so I apologize for that.

However, I'm not familiar with the Standard Edition of this product, so I don't exactly know what makes it different from the Professional Edition. 'cause I was inclined to suggest you get the latest 6.31 update to be sure you could support all OSes (e.g. Windows XP) and would in the best situation possible for that series, but I don't see such a download for that edition of the product.


Now as for your actual problem, I understand what you're saying and I did some additional checking since I don't use Maintenance mode personally. Now, based on this InstallShield Community posting, it seems all of this is standard behavior.

Despite that being the case, I have a suggested workaround. I would hard code a custom "Copy to Folder" path along the lines of the following:
  • %PROGRAMFILES%\InstallShield Installation Information\<ProductGUID>\Maintenance
  • %WINDOWS%\Cache\<ProductGUID>
  • %WINDOWS%\Downloaded Installations\<ProductGUID>
  • %WINDOWS%\Installer\<ProductGUID>
This will of course force to go to one of the standard Maintenance-related locations and, as a result, continue to be available afterwards.

Now, to address your concern about the files never being deleted, there's an easy way around that. You would just need to modify your OnMaintUIAfter portion of the script to do this additonal cleanup in the event of a Removal. There are several ways to implement, but one of the easiest would probably be to write a command of like "del /Q <PFTWPath>\*.*" to the folllowing area of the registry:

HKLM\Software\Microsoft\Windows\CurrentVersion\RunOnce

Well hope it helps then and good luck.
user posted image

meemax

meemax
  • Members
  • 10 posts

Posted 18 May 2005 - 02:08

When you said "del /Q <PFTWPath>\*.*", does <PFTWPath> stand for the path where I "hard-coded" the "Copy to Folder" path? I tried it and got the message that "del" was an unknown command or something.

Another thing (and this is probably a dumb question), where might I "hard code" the "Copy to Folder" path without allowing PFTW to display the "Location to Save Files" dialog? As far as I know (please do correct me if I have misunderstood something), in later versions of PFTW I could use the /px command line parameter to skip the "Location to Save Files" dialog but this does not seem to work in my current version (PFTW 3.0).

coz the way i see it, if i can't stop the "Location to Save Files" dialog from appearing, the user will have the option to change the pftw path; If so, I might not be able to delete it in OnMaintUIAfter as you had suggested, since there seems to be no way of knowing the actual PFTW path.



Thanks a lot. I really appreciate it.

Edited by meemax, 18 May 2005 - 06:28.


Taco Bell

Taco Bell

    IS6 Expert

  • Moderators
  • 1,281 posts

Posted 20 May 2005 - 19:12

Sorry for the delay in my response, but I was out of town the past couple days.


Yes, the <PFTWPath> is the hard-coded path to which the setup was extracted, but you should also be able figure that out on-the-fly by using InstallShield' SRCDIR system variable.

As for locking out that location, using the system variable should eliminate that need. However, I was assuming that PFTW 3.0 also has the checkbox of "Allow end user to modify destination". With this box being unchecked, the hard-coded path will still be displayed, but it should be grayed out. I'm also not familiar with the /px switch, but checking the v4.0 help, I do see that one being documented. Therefore, is there any reason you can't move to that newer version of the software? I know IS recently pulled their download link, but it's freeware, so I could send you a copy of the setup.

Finally, now that you mention it, I don't think RunOnce will accept a system command such as del. In that case, you'll have call a DLL function. I would recommend calling the function "MoveFileExA" in the DLL SYS32\Kernel32.dll. It takes the following parameters:
  1. lpExistingFileName (string pointer), so in your case "<PFTWPath>\*.*".
  2. lpNewFileName (string pointer) where NULL causes the lpExistingFileName file to be deleted when the system restarts. However, despite the expectation of this being a string pointer, I actually a dword with a value of zero to do my deletion. Either may work though.
  3. dwFlags where a value of 4 is MOVEFILE_DELAY_UNTIL_REBOOT.
The resulting return code is a long.
user posted image

meemax

meemax
  • Members
  • 10 posts

Posted 03 June 2005 - 07:08

THANK YOU VERY MUCH!