Aug 31, 2020
07:41 AM
UPDATE: The registry entry seems to stem from an external *.reg file that is associated with the Component via the "REG File to Merge At Build" setting. However, that REG file hasn't changed during the migration. Has InstallShield changed the way, registry entries from *.reg files are interpreted / processed? The registry entry in question in the *.reg file looks like this: [HKEY_LOCAL_MACHINE\Software]
With just an empty line underneath, then the next entry is listed. Can I make any changes here that tell InstallShield to create the entry if it doesnt exist but not delete it on uninstall (i.e. Registry Name="+" instead of Name="*")? Alternatively I will try to just delete that entry, as the "Software" key should always exist anyways. But this behavior is quite strange.
... View more
Aug 31, 2020
07:05 AM
We have recently migrated an older IS project (build with InstallShield 12) to InstallShield 2020 RC1. The actual installation after the migration works fine but we're having an issue during uninstallation. Specifically, it seems that the installer is attempting to remove the entire "HKEY_LOCAL_MACHINE\SOFTWARE\" subkey for some reason. Here an excerpt from the install log: MSI (s) (A4:CC) [11:29:52:948]: Executing op: RegOpenKey(Root=-2147483646,Key=Software,,BinaryType=0,,)
MSI (s) (A4:CC) [11:29:52:948]: Executing op: RegRemoveKey()
RemoveRegistryValues: Key: \Software, Name:
MSI (s) (A4:CC) [11:29:53:104]: Note: 1: 1402 2: HKEY_LOCAL_MACHINE32\Software\Microsoft\EAPSIMMethods\18\FastReauthContext 3: 5
Info 2835.The control ErrorIcon was not found on dialog SetupError.
Error 1402.Could not open key: HKEY_LOCAL_MACHINE32\Software\Microsoft\EAPSIMMethods\18\FastReauthContext. System error 5. Verify that you have sufficient access to that key, or contact your support personnel.
MSI (s) (A4:CC) [11:30:05:198]: Product: EVOware 2.8 Service Pack 4 -- Error 1402.Could not open key: HKEY_LOCAL_MACHINE32\Software\Microsoft\EAPSIMMethods\18\FastReauthContext. System error 5. Verify that you have sufficient access to that key, or contact your support personnel. This of course fails, because some of the subkeys seem to be protected (in this case, the "FastReauthContext" key). To retrace it, I opened both the pre-migration and post-migration MSI in Orca and I indeed found corresponding entries in the Registry table that access the "Software" subkey, although they did have one key difference: In the pre-migration installer the "Name" column was "+", in the post-migration installer it is "*" which does explain, why it is attempting to delete the "Software" subkey. However, I am confused why the migration would even change that in the first place. But be that as it may, now to the part that I can't figure out: In both versions of the installer, the registry entry is associated with the same Component according to Orca. However, when I look at that component in the migrated InstallShield project in the InstallShield editor, it does not have any associated registry entries at all. Also, the registry entries in both versions of the installer have different Registry identifiers. From what I can tell, for most other entries in the Registry table, the Registry identifiers have not been changed in the migration. If I open the IS project file in notepad, I cannot seem to find either of the Registry identifiers in it either. Any ideas on how to track this registry entry down in the InstallShield editor to fix it? I don't want to have to patch the installer via Orca or anything like that.
... View more
Labels
- Labels:
-
InstallShield 2020
Feb 05, 2020
06:27 AM
We have an installer project based on InstallShield 12 that has been failing to build correctly since starting the build cycle again this year. More specifically, the standalone InstallShield build (with IsSABld.exe), starts off building our install scripts, builds the Directory/feature/component/file table etc. and then just stops the build but doesn't throw any errors. When comparing with previous logs, at this point the InstallShield should start integrating the merge modules - which are still available and the paths to the merge modules are still correct. I've attached a log from a faulty build. InstallShield still outputs an .msi but not the corresponding Setup.exe. Though the .msi is obviously incomplete, it should have a file size of around 27mb but in this case is about 80kb. The strange thing though is that the exact same InstallShield Project built just fine in November of last year. I can verify that nothing in the InstallShield project (or in the entire build environment) has changed since then - the exact same issue occurs when building after recovering a backup of the build system on the date of the last successful build. There are also no external dependencies outside of the build environment that have changed. Is there maybe any extended/verbose logging for the InstallShield build that I could activate to diagnose this issue? Any other possible causes that I could check for? Thanks.
... View more
Labels
- Labels:
-
InstallShield Legacy Versions
Latest posts by dariom
Subject | Views | Posted |
---|---|---|
850 | Aug 31, 2020 07:41 AM | |
853 | Aug 31, 2020 07:05 AM | |
951 | Feb 05, 2020 06:27 AM |
Activity Feed
- Posted Re: Retracing faulty Registry key entry on InstallShield Forum. Aug 31, 2020 07:41 AM
- Posted Retracing faulty Registry key entry on InstallShield Forum. Aug 31, 2020 07:05 AM
- Posted InstallShield Standalone Build stops mid-way but without errors on InstallShield Forum. Feb 05, 2020 06:27 AM