whats wrong with this installshield version?????

[anilkumar_mca]

Hi,
I am using a installshield evaluation version. its details are:

File version: 15.0.0.591
Internal Build Number: 82160
Product version: 15.02.0000

The following image shows that i am using SP2, but i am facing some issues which are mentioned in the Installshield 2009 known issues and resolved issues, which are available in below links:
resolved issues:
http://kb.acresso.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&externalId=Q200150&sliceId=

known issues:
http://kb.acresso.com/selfservice/viewContent.do?externalID=Q200152

i tried to install some service packs which are downloaded from:
http://saturn.installshield.com/product/is/2009/domestic/sp2/Update.exe

when i tried to install this patch, i got the following error:

Can anybody tell me whats wrong with my installshield????:(

[anilkumar_mca]

Hi,
please help me to know where is the issue ? let me know if u want any other information!

[SherylSikora]

The product information that you have supplied indicates that you have a successful installation of IS 2009 SP2. It appears that you are trying to install a patch that has already been installed on your machine - hence the "Service Pack 2" indication in your screen shot.

If you want to be sure that the patch has applied correctly, you might want to uninstall your IS 2009 install, re-install the base IS 2009 install and then reapply the SP2 patch.

If you are still seeing any of the issues that have been listed in the Release Notes for SP2, please let us know which ones in particular.

[anilkumar_mca]

Hi SherylSikora,

Thanks for your replay.
I installed IS2009 SP2 by re-installing the base IS2009.
Still i am facing the following issue:
I am upgrading IS12 to IS2009. In 64Bit machine, i am unable to uninstall my application. While debuging i noticed that the following statement is always TRUE:
if(!MAINTENANCE)

i feel i am facing the issue ('IOC-000072553, IOC-000072555 (InstallScript MSI)' ) which is mentoined in Resolved issues of SP2.

From last 30 days i stuck with this issue, its a big work stopper to me.... pls help........

[joshstechnij]

After installing your project, can you check to see if the following are present:
- In the registry, HKLM\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\InstallShield_{ProductCode}
- C:\Program Files (x86)\InstallShield Installation Information\{ProductCode} (there should also be a file named setup.ilg in this folder).

If the above items are not present, that would seem to suggest that the built project does not include the code fix for the work orders you mentioned.

[anilkumar_mca]

Hi,
I checked in the above location, both registry entry and setup.ilg file was not there.
When compared the registry keys before and after installing my application, setup.ilg file is getting created(as per registry entry), but it was not there when i checked in that location.

But i created a dummy project in IS12 and upgraded to IS2009, it is working fine as expected(above registry entry & .ilg file was there).

Is there any settings required in my project ?????

[joshstechnij]

If the setup.ilg file is not present, the setup (from the InstallScript engine's point of view) will think it's not installed and always run as a first time install. The InstallScript log file (setup.ilg) will be copied to the Installation Installation folder at runtime (of a first time install) if the MSI portion of the product was registered.

If this is only happening with one project, I would recommend trying the following troubleshooting steps:
- Replace the setup.rul file in your project with a default setup.rul. Then, rebuild and test the project again.
- Verify that you have the following actions in the install execute sequence and that they are not conditioned: RegisterUser, RegisterProduct, PublishFeatures, PublishProduct. If they are missing or have conditions set, these actions should be restored to the sequence and conditions used in a new project.

Please let me know what your results are.

[anilkumar_mca]

Hi joshstechnij,

Thanks for your replay.
For your information, I am not changing any option or script while migrating from IS12 to IS2009, Except
\SkinsMSI\Blue.skin to \Skins\Blue.skin

I am facing this issue for all(4) the 64Bit installers. I done the changes that u mentioned, but no use. The changes can be seen in below image.

I again created a sample project in IS12 with
- a sample dll
- registry creation
- sample script
- skin as \SkinsMSI\Blue.skin
and i converted to IS2009. Its working properly.

Almost, I made all the options (in sample project and in actual project) as same. But no use.....

It seems some settings is required in my actual project. I am not getting what it is.... 😞

Hai Forum, is anybody faced this issue???????

[joshstechnij]

There are no specific settings required to be set or not set to get a 64-bit installer to appear in Add/Remove Programs and to run in maintenance mode after a first time install.

Can you send me one of your project ISM files and rul files that reproduces this behavior?

[anilkumar_mca]

Hi,

Can you please send me your email-id, so that i can send my project to you. As it is a company project i cant send it to public forum.....

[joshstechnij]

You can send the project to joshs@acresso.com.

[anilkumar_mca]

Hi,
I send my project as an attachment to your mail. please verify it and let me know where was the issue..........

[joshstechnij]

I've been able to reproduce the behavior you are seeing. The uninstall key is being placed in the registry in the wrong location (64-bit registry instead of 32-bit) because the REGDB_OPTION_WOW64_64KEY option is set in OnBegin. Removing this properly creates the uninstall key in the correct location. You can resolve this issue by turning off the REGDB_OPTION_WOW64_64KEY option at the end of OnFirstUIBefore.

There is some other code in the script that is causing the setup log to not be created. I have not been able to track down what specifically is causing this behavior at this point. When I have more information I will reply to this thread.

[joshstechnij]

The issue with the setup log not being created is caused by changing the UNINSTALLKEY variable after the uninstall key has been written by the InstallScript engine. The uninstall key (starting with IS 2008, if I remember correctly) is now written immediately after the MSI package has finished installing (this allows for modifying the key before the script exits).

To set a custom unininstall key name, move the code that is setting UNINSTALLKEY and UNINSTALL_DISPLAYNAME (in OnFirstUIAfter) to an earlier point in the script, such as the end of the OnFirstUIBefore event.

[anilkumar_mca]

Hai joshstechnij,

Thank you very much......... all my uninstallation issues for 64Bit and 32Bit was resolved with your help. 🙂

Two more small doubts.......

Can u tell me,
1. Is setting REGDB_OPTION_WOW64_64KEY option is necessary for 64Bit installers in IS2009?

2. One of my 64Bit installer is unable to register a .dll(it is a self-register dll). Is there any link between self-registration and REGDB_OPTION_WOW64_64KEY option? If yes where i have to set this option? If no what will be the reason for the failure of registering?

Once again thanks for your help.........

[joshstechnij]

The REGDB_OPTION_WOW64_64KEY registry option is needed only if you are attempting to read or write to a 64-bit location in the registry on a 64-bit machine. Because the InstallScript engine is 32-bit, this option is provided in order to be able to access 64-bit registry locations. If you never need to read or write 64-bit registry locations, setting this option would be unnecessary.

Regarding DLL self registration, if you are using COM extraction to register the DLL, and the component containing the file is marked as 64-bit, then Windows Installer will automatically create any COM registry information in 64-bit registry locations. If the DLL was marked as self registering, the Windows Installer SelfReg table would need to be used to register the DLL. The REGDB_OPTION_WOW64_64KEY option does not have any affect on how a DLL is self registered (this option has no connection to Windows Installer self registration options and does not change how the InstallScript engine attempts to register DLLs). Without knowing what the failure is that you are seeing, I can't offer any more detailed information.

[anilkumar_mca]

HI,

Error:
'error 1904. Module C:\Program Files\MyCompany\....\Mydll.dll failed to register HRESULT -2147220473. Contact your support personel.'

Information:
I am able to register that dll using regsvr32 from command prompt.
The dll i am trying to register is a COM dll.
Same dll is getting registered in 32Bit environment through the installer itself..
This registration is working fine before migrating from IS12 to IS2009 also..........

[joshstechnij]

What table are you using to self register this DLL (MSI SelfReg or InstallShield ISSelfReg)? If you're using the InstallShield table, the DLL will not successfully register (the ISSelfReg support cannot load 64-bit DLLs). In this case, the record for the DLL should be removed from ISSelfReg and added to the SelfReg table.

Another thing to note is if there are missing dependencies required to successfully register the DLL, it will fail to register. The most common cause of this recently is a dependency on Visual C++ 2005 or 2008 runtime DLLs, which are Win32 side-by-side assemblies. Due to how Windows Installer installs assemblies, self registration with either table or regsrv32 (through a custom action) will fail before InstallFinalize (assemblies are not committed until after InstallFinalize, and both self registration tables run self registration before InstallFinalize).