DevStudio -> InstallShield 2008 = COM problem?

[timelox]

I'm currently evaluating InstallShield 2008 and will buy it as soon as my DevStudio 9 script works as expected.

I have an InstallScript MSI Project that do install alot of COM components.
Our current script is built with DevStudio 9 SP 1 and it installs fine on Windows Vista.

For testing I have migrated the script to the EVALUATION VERSION of InstallShield 2008. However, if I install that on Windows Vista the COM components fails to work.

Our applications calls the WinAPI CoCreateInstance(...) to access the COM components.
With the DevStudio 9 built script the calls to CoCreateInstance() returns S_OK.
But with the InstallShield 2008 built script the calls to CoCreateInstance() returns E_NOINTERFACE.

So there is something different during the COM Extraction phase between DevStudio and InstallShield 2008. Not all settings seems to be extracted. Any known bugs? Something I can change in my script?

Please help.

PS. I have added the DWORD registry key 'ExtractTypeLibsToRegistryTable' (= 0) under 'HKCU\Software\InstallShield\14.0\Professional\Project Settings' and rebuilt the script with the same result.

[MichaelU]

It's a little unclear to me where to start, so I'm going to throw out a few questions to help target any fixes. You say the DevStudio 9 install works fine on Vista. Does the InstallShield 2008 install work on XP? Do you do any manual or self-registration of COM information from InstallScript code, and if so what event or custom action is it called from? Have you tried setting the Required Execution Level to Administrator on the Releases view, Setup.exe tab, and if so does that get the desired behavior? Correspondingly have you ensured the General Information > Summary Information Stream option Require Administrative Privileges is Yes (it should have been by default)?

[Christopher_Pai]

I'm confused also, most of your post seemed to make me think you were calling selfreg methods from script and that UAC issues might be your problem, but then at the end it sounded like you were using COM extraction and that the extraction pattern was failing.

Eitherway I'd avoid SelfReg and COM extraction at build time. Get your components properly authored with COM extraction data and things should go well at build and install time.

[timelox]

Sorry I was not clear enough I'll try to rephrase the problem in a clearer way.

My script installs a little more than 20 COM comoponents. Since I'm only the developer for some of those I never know when the rest of them change (and they do change sometimes). That's the reason I've selected "COM Extract at Build: YES". I've been using that option since it was implemented in InstallShield products and always with a successful result (until now?).

Michael Urman
Require Administrative Privileges on the Summary Information is set to Yes but the other option Required Execution Level on the Releases view, Setup.exe tab was set to 'Highest Available'.
Anyway, I am installing this as the Administrator both with UAC on and off (same result).

Christopher Painter
I guess it's a matter of the other developers being lazy not telling me when their COM components have changed. I will try setting the COM Extract at Build to NO but why do you have the option to extract the info during build time if it doesn't work?
If COM extraction at build time do not work how do I get the correct registry information with this option set to NO?

As I wrote earlier, our application fails after installation (i.e. CoCreateInstance(...) returns E_NOINTERFACE).
However, if I turn off UAC and manually register all the COM components with xxx.exe /RegServer and regsvr32.exe xxx.dll then our application works fine (i.e. CoCreateInstance(...) returns S_OK).
So it most definitely is something not right with the COM Extraction.

[timelox]

Michael Urman
Switching Required Execution Level to Administrator made no difference.

Christopher Painter
I changed all COM components to not extract COM info during build and did a Extract COM Data for Key File on all of them.
It made no difference, still the same problem.
I then changed back to the new COM extraction by changing the registry key value of ExtractTypeLibsToRegistryTable to 1 and refreshed the COM Data for Key File and rebuild the script.
Still the same problem...I'm out of options now. Do you have more idéas for me to try?

[Christopher_Pai]

Sounds like you have to do COM extract at build then.

Can you take one of your DLL's, put it in a test project by iteslf and build it on both versions of IS? Then compare the tables.

COM Extraction has generally improved over the years, but there are still times that it fails. Usually an MVSN employee will chime in with a quick fix or ask for a copy of the DLL and come up with a patch.

[DLee65]

timelox,

I have been following the discussion here. One thing I would try is to open "C:\Program Files\Macrovision\IS2008\Support\RegSpyUI.exe"

this will graphically show you want InstallShield sees with your COM objects.

I know that InstallShield has done a great job in improving the COM extraction over the years. I have been using it since DevStudio 9 days and it has worked reliably for the most part. I had one problem but it turned out to be a problem with a dll declaring the interface without any contents, so the problem was on our part.

[timelox]

It's been a long time since I last used the RegSpyUI.exe (had forgot about it).

I used the RegSpyUI from InstallShield 2008 on one of the COM components I know fails after installation and compared it with RegSpyUI from DevStudio 9.

Guess what...RegSpyUI from DevStudio extracts more keys.

The new RegSpyUI do not extract the Interface keys and the TypeLib keys.

When I think of it, the error from CoCreateInstance was just that (i.e. E_NOINTERFACE).

So Christopher, where do we go from here? I guess I could manually hack those missing keys into the tables of the script but that's not the way to go.
I prefere solving the problem with the code behind the new RegSpyUI instead.

Regards,
Magnus

[DLee65]

Remember that the release notes for IS 2008 state that COM extraction for TypeLib table is deprecated. These should be extracted to your registry table now.

I seem to recall that there is a way to revert to extracting to the TypeLib table but I cannot recall the method off the top of my head.

[timelox]

Q113259 but the result is still the same and this fix is for the TypeLib only, not the Interface which is also missing in the new ReySpyUI extraction.

I'm not sure if I need the old way or not since the user installing the script is not the same as the one running the installed application. However, both the Interface and the Typlib info must be present when launching our application.

[DLee65]

Yeah, I figured as much. The only thing I could think of was the issue with TypeLib and the new RegEdit. Perhaps MikeM could coordinate things to look at a dll if that is permissible for your company.

[timelox]

I will be absent next week but will be back again on monday the 9th of july.

If any of the InstallShield developers would like to help me with this critical issue you have a week to figure something out.

If nothing happens during the next week I'll open a support case to speed things up (guess that's the right way to do it anyway).

[joshstechnij]

Another change to the COM extraction was made in InstallShield 12 to use the Windows registry API RegOverridePredefKey (http://msdn2.microsoft.com/en-us/library/ms724901.aspx) instead of API hooking which DevStudio would have used. This change fixed some issues with COM extraction failing on some Windows 2003 installations and various other issues we were seeing with the old method.

One side effect of this change can affect registration that attempts to read from the registry while the module is registering itself. For example, if the DllRegisterServer function in a DLL attempts to do a read from a registry key or value and then conditionally performs its registration based on the information returned, the new COM extraction method will cause no data to be returned. This is because we remap the "view" of the registry with the RegOverridePredefKey API. Are any of your DLLs that are failing to register performing any such conditional registration?

Can you try adding the following key/value and see if the behavior changes?
HKEY_CURRENT_USER\Software\InstallShield\RegSpy
REG_DWORD: UseAPIRegistryHooks, value: 0

[timelox]

The COM components are plain MFC/ATL components with the default registration behavier (e.g. '/RegServer' will call _Module.RegisterServer(TRUE);
).

The key 'UseAPIRegistryHooks' made no difference. The interface and typelib is still missing.

[timelox]

After turning UAC back ON and changing the Local Security Profile to automatically elevate, running RegSpyUI as administrator will properly extract all the keys.
I assume running IS2008 IDE as administrator will have the same effect for "Extract COM at build".

[Drizzt]

Hi,

I am also experiencing the same problems as TIMELOX. My issue is with the Missing Interface keys during COM Extraction in AdminStudio 8.5 Editor (The same as InstallShield 2008?). The Interface keys are extracted successfully when using RegSpyUI.exe. Is there something I am missing, or do I need to manually add the Interface keys after InstallShield completes its COM extraction? By the way my OS is XP.