cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Barbara
Level 7

Problems with COM extraction with IS2009 in comparison with IS 12

I recently upgraded my projects from IS12 to IS2009 and find that for some DLLs the COM extraction is not working with IS2009 as for IS12. Both InstallShield versions are installed on the same machine and have the same settings. I use also the registry key HKEY_CURRENT_USER\Software\InstallShield\RegSpy, DWORD: UseAPIRegistryHooks, Value: 0, on the build computer. If I compare the results of the RegSpyUI12 and RegSpyUI2009 for some of my MMC SnapIn DLLs I can see that with RegSpyUI2009 twelve less registry keys are extracted than with RegSpyUI12 (for the same DLL). The same behaviour is seen during build, with the result that the installation generated with IS2009 is not working on the target machenine because the SnapIns are not loaded into the Microsoft Management Console. As I can see from RegSpyUI all the keys connected with the MMC are not extracted with IS2009. I attach two RegFiles, one containing the complete information extracted with IS12 and one containing the output for IS2009. Maybe someone has a hint for me what to do.

Barbara
Labels (1)
0 Kudos
(12) Replies
MichaelU
Level 12 Flexeran
Level 12 Flexeran

I think your files didn't get attached. If you could describe or list some of the keys that are missed, that might be all we need. I know that we are more likely to filter empty keys now than previously, so that might explain things if these are keys without any values in them.
0 Kudos
Barbara
Level 7

Next try to attach the zip-file.
The registry keys which are not extracted are mainly connected to the Microsoft MMC registration. This are empty and not empty keys.

Barbara
0 Kudos
MichaelU
Level 12 Flexeran
Level 12 Flexeran

Are you certain this comes from the same DLL (or set of DLLs)? And not just the same source, but actually the same files?

The empty key thing I described applies to items like HKCR\CLSID\{...}\Programmable, although that particular case should be fine. When I diffed these two files, in addition to the several keys or branches that were missing, HKCR\Interface\{...}'s default string changed from "clsCallback" to "_clsCallback". This change doesn't seem quite like something I'd expect to be caused on our end; does it ring any bells on your end?

Finally, if you have the 64-bit COM extraction beta installed, make sure to try without it (and please let me know if it makes the difference).
0 Kudos
Barbara
Level 7

Michael,

I am also a little bit confused by my findings, so I double checked all the results.
1. Yes I am absolutely sure to use the same file (from the same place in the filesystem) in all the cases.
2. I didnt use the 64-bit COM extraction beta: At my first attempt it was installed on my machine and I suspected it to be the one making the trouble. I removed it but got the same results.
3. "clsCallback" versus "_clsCallback": I didnt develop this dlls, so I will talk to the developer, maybe he has a hint. But I have seen this behaviour sometimes before, never having a negative impact.
4. Made another test: I have two identical build servers, one installed with IS12 StandAlone build, the other with IS2009 StandAlone build. On the IS12 buildserver I copied the files RegSpyUI.exe (from the IS12 develop environment) into the directory C:\Program Files\Macrovision\IS 12 StandaloneBuild\Support, also the file IsRegSpy.exe into the directory C:\Program Files\Macrovision\IS 12 StandaloneBuild\System. I started RegSpyUI and it gives me the correct registry data. I made the same on the IS2009 buildserver with the analog files from the IS2009 develop environment, started RegSpyUI and can see that part of the data are not extracted.. Then I copied the two IS12 files (RegSpyUI.exe and ISRegSpy.exe) in the analog directories of the IS2009 buildserver, started RegSpyUi and got the correct registry data.

Barbara
0 Kudos
MichaelU
Level 12 Flexeran
Level 12 Flexeran

Hmm. It sounds like the last gives you an effective workaround, at least. I believe (my memory's hazy) IS12 through IS2009 use a proxy key under HKLM so the files should be interchangeable with few or no ill effects. (Just make sure to also copy IsRegInj.dll if you COM Extract EXE files.) But longer term this exchange won't work as we plan to move to HKCU to better support 64-bit extraction. Is it possible for you to send me the DLL (and any register-time dependencies) so we can examine this further?
0 Kudos
Barbara
Level 7

Copying the files IsRegSpy.exe , RegSpyUI.exe and IsRegInj.dll from the IS12 environment to the IS2009 environment does only work if I start the program RegSpyUI directly. It does not work during the normal build process. I get the following build error for every component marked for COM-extraction:

ISDEV : warning -4354: The build was unable to extract COM information from the file \\intranet.procad.de\setup_gen\SetupGen_820\Zusatzmodule\ProAdmin\N\AdmBomHeaderSnapIn.dll in component AdmBomHeaderSnapIn.dll. Please ensure that the file is self-registering and verify that the self-registration process does not fail.


So do I have to copy some more files or must they be registered or ... ?

I attach you a DLL which, I hope, has not so much dependencies, so that you can use it for testing. The attached ZIP-file contains: The file ProOffice.dll for which the COM-extraction should be done. The file MSADDNDR.DLL which must be registered on the system. Two Regfiles which I extracted with IS12 and IS2009 for this Dll.

I made some other tests and think I found a hint where the problem could be:
I set up a brand new W2K3 server and installed IS12 and IS2009 on it. Then using the COM extraction for both IS versions gives me the wrong result ( to less registry keys extracted ) for both IS12 and IS2009. As a next step I added the registry key HKEY_CURRENT_USER\Software\InstallShield\RegSpy, DWORD: UseAPIRegistryHooks, Value: 0, and this gives me the correct COM extraction results for IS12. IS2009 seems not to be affected by this registry key, it nevertheless extracts to less registry keys. So maybe the reason ist that the IS2009 COM extraction is not affected by the UseAPIRegistryHooks value ?

Barbara
0 Kudos
MichaelU
Level 12 Flexeran
Level 12 Flexeran

Okay, I think your comment about needing to register MSADDNDR.DLL first is the main culprit here. During self-registration of ProOffice.dll, process monitor indicates that it attempts to open HKCR\CLSID\{AC0714F7-...} which is one of the keys that MSADDNDR.DLL itself registers. When it doesn't find it, it probably decides not to register some of its capabilities.

In the new style COM extraction, each file is registered in what is essentially a clean registry, but with some well-known keys prepopulated. When the API hooks are used (the old version), each file is effectively registered in the normal registry and thus can read already-registered files. If your machine that yields fewer keys didn't have MSADDNDR.DLL pre-registered, this would likely explain the difference.

However the final symptoms you report make it sound like IS2009 no longer supports the old style COM extraction correctly. This isn't intentional, so it may represent a bug. That said, I'm not sure what my recommendation is. You could try the IS2008 DLLs if you have them (perhaps they won't have the root change that is likely plaguing the IS12 to IS2009 case), and longer term, perhaps we can add a way to ensure some custom registry keys exist in the otherwise clean registry (whether by being copied from the real one, or by being specified in a file).
0 Kudos
martinbe
Level 3

I had the same problem with Com extraction form some dll's in Installshield Premier 2009 which gave no problem in Installshield Premier 11.

If I run as an Administrator however the COM extraction does work:)
So that's a workaround you can try.

Note I do hope that another solution is possible because running as an administrator is not preferable for me.
0 Kudos
Barbara
Level 7

So far so bad 😉 . I tried IS 2008 and found the same behaviour as for IS 2009. So I am a little bit helpless what to do.
1. Go back to IS12 for all my 35 setup modules --> but I wanted to use the newest release because there are some other features I need.
2. Change from dynamic COM extraction to static Reg-files added during build --> a lot of work to do in order to make all the regfiles needed. And I always liked this dynamic COM extraction more than the static regfiles.
3. Some other suggestions ?

@martinbe: Thank you for your hint. But it is not working for me.

Barbara
0 Kudos
MichaelU
Level 12 Flexeran
Level 12 Flexeran

@martinbe: Unfortunately the methods we use for COM extraction do not appear to work unless running as administrator. There's no documentation of this on the MSDN page for the API, nor do I think there were any failure codes; they just don't work otherwise.

@Barbara: Drat. I've filed IOC-000075504 to provide a way to ensure dependent keys are available during COM extraction. In the meantime, here's some brainstorming ideas for how to cope with it now:

If your DLL is fairly static, and its install needs simple, create a merge module in IS12 with the DLL or DLLs and its (their) registration information. There shouldn't be any funny business in this DLL to worry about which version created it, so it should be clean to merge into an IS2009 project.

If it's fairly dynamic and your build machine can work with both standalone builds, you can still use this strategy, but it's a more complicated build script.

If it's dynamic and you can't easily use both build environments, or its needs are too complicated for a clean merge module, we need better ideas. 🙂
0 Kudos
Barbara
Level 7

I think I have to do it the hard way: Use static Reg-files for each component with COM-extraction and hope that the registry information does not change so often. I have a highly dynamic build environment (files from the nightly build are automaticaly copied to the setup build directories) so I am not able to use merge modules. I hope there will be an easier solution soon.

Barbara
0 Kudos
max-power
Level 2

Hi Barbara,

Did you manage to find a solution to this? I have a similar problem (http://community.flexerasoftware.com/showthread.php?206993-IsRegSpy-exe-and-RegSpyUI-exe&highlight=isregspy) that is causing an issue!

Thanks!

UPDATE: Fixed it with the solution in my post 🙂
0 Kudos