View Full Version : COM Extraction Still has problems

09-24-2003, 09:01 AM
Posting here as the mysupport site doesn't appear to be working currently.

I have an exe which the RegSpyUI.exe tool correctly determines the InProcServer32 information , but the COM extraction mechanism in the project doesn't determine the correct information.

We've reported COM extraction problems before with other files in the project before so if I.S. tech support could contact me with an email address I can provide a sample bundle of files.

You still there Rich.... ?

We've stuck on Developer 7 for now as we have it stable with the workarounds I've done. I was hoping to upgrade to v9 but if its still got the same old problems then theres not a lot of point...


09-24-2003, 10:03 AM
What problem is that?
I am also using IS Dev 7.04 and I seem to have difficulties upgrading a registered dll (using COM extraction) with a minor upgrade. I was wondering if the problem you are refering to is similar.

09-24-2003, 10:19 AM
This isn't with an upgrade and i'm using v7.03 (7.04 was deemed too buggy for use)

I have a component which if removed from the project and put back in with the Component wizard (and choosing not to extract COM info at runtime) adds entries into the registry section and into the COM registration section (6 enties). When Installed all the Inprocserver32 entries get set as the component for which got added. However 3 of the Inprocserver32 entries should point to a support dll which is also included in the project - and is registered on the build system. I end up hacking round it by importing in reg files for the component which overrides the automatically generated info. So we forget about using the validation checker as we're having to break the rules just to get it to run.

This ( and variations of) occurs on some of the 40 ish odd files i'm installing - we have a custom program to check every single component registry entry is correct every time we do a release. as at present we can't trust the COM extraction wizard to work properly.

09-24-2003, 10:50 AM
I appreciate your update.
Fortunately for me, I don't have to use the COM Extraction feature very much but when I do, it also seems to not work as expected.
I see that you've done a lot of research on that problem, and wish I could be more helpful.
I too hope to see an enhanced handling in that department from IS in future release versions of IS Dev, maybe with more flexible options. Good luck

Art Middlekauff
09-24-2003, 11:24 AM
COM extraction in Dev 9 (and Dev 8 for that matter) is stable and reliable. There are very few situations in which it will not give correct results. In your case you state that "all the Inprocserver32 entries get set as the component for which got added. However 3 of the Inprocserver32 entries should point to a support dll which is also included in the project". Are you describing this situation:

1. Self-register A.dll.
2. A.dll's self-registration code creates a registry entry setting inprocserver32 to B.dll.

09-24-2003, 11:58 AM
The A, B layout is correct however we only perform a manual registration on the build machine to get the component registered. We are trying to follow the setup guidelines and have MSI perform the registration within the project so we do not have the component self-register property set in the setup-project nor do we register it in installscript.

What is interesting is that the regspyui program displays the correct output.

I have spoken to the developer of the component who believes that according to the Microsoft specs the A refers to B Inprocserver32 style is a legitimate coding practice/style.

I can provide a reg file/source files for example on a private channel if this will be of assistance.

We did have a hotfix produced by Fei for a bug in the Installshield 7 COM extraction mechanism, but if v 8/9 has been significantly improved I'm open to attempting a reassessment of where the problem might be for this item.



Art Middlekauff
09-24-2003, 12:11 PM
N. Lawrence,

As you know, the problem is not with RegSpy because it correctly identifies what the self-registration code is doing.

Also, I do not intend to cast doubt on your developers. What you do in self-registration is completely up to you and there is a great variety in how developers approach this.

The problem lies with Windows Installer. We take the output from RegSpy and must cast it into the Windows Installer tables. We use the InProc value to determine how to populate the Class and other tables. This process currently does not support having one file register another.

However, RegSpyUI now supports a command-line interface and it also supports saving the output to a REG file. Perhaps you could use this and import the REG file into your project.

We have a work order about something similar: 1-8YU5V. This may have been created when you encountered this issue with Dev 7. Please email me (artm@installshield.com) so we can confirm that this is the same issue.

- Art