installshield not extracting all COM registry from dll

[yann_bertaud]

All,

I have a found a major problem with installshield 2008. Our product uses a lot of COM registry stuff in it's dlls. As such we depend on IS to extract all COM from the dlls at build time. We thought this was reliable, unfortunately it is not. I have run into this a few times now with several different dlls in our product.

As a test i tried the following:
1. use regspyui to extract the COM from the dll. end up with a .reg file that appears complete.
2. in installshield, use the component wizard to add same DLL and turn on Extract COM immediately. Look at the registry for the newly added component. Some of the registry info is missing.
3. again in installshield, use the component wizard and add the dll, this time turn off extract COM immediately.
4. in the component view, turn on Extract COM at build.
5. Build the installer. Open the resulting MSI in installshield. Inspect the registry for the component.

Result: same keys are missing as in step 2.

Am wondering if any one has run into this? if so, did they come up with a solution? this is making us really question the reliability of installshield with regards to COM info and makes us understand why we have been having so many problems with our installer.

thanks

Yann

[Christopher_Pai]

Truthfully, COM extraction is a bit of black magic. Get too little and it doesn't work, get too much and you can hose up a machine:

http://blog.deploymentengineering.com/2007/08/hotfix-com-extraction-causes-system.html

I don't reccomend com extraction at build. Use the one time COM extract and then manually alter the data if needed. Build, test and from then on you should be OK.

The only time I reccomend COM extraction is when you are dealing with COM servers that aren't binary compatible from one release to the next. But I don't reccomend that either and truthfully I'm glad I'm mostly .NET these days.

[MichaelU]

One other comment, because it's not clear from the post whether this happened: ideally most COM registration information will be separated out and put into semantic tables like the Class or ProgId table, and thus the registry keys they represent would not be put into the Registry table. Did you see if the information you know is missing was accounted for in one of the COM tables?

[yann_bertaud]

MichaelU wrote:
One other comment, because it's not clear from the post whether this happened: ideally most COM registration information will be separated out and put into semantic tables like the Class or ProgId table, and thus the registry keys they represent would not be put into the Registry table. Did you see if the information you know is missing was accounted for in one of the COM tables?

I did not look in the other tables, but I do know that when the product is installed, there are missing registry keys. Registering the dlls manually after the install adds the missing registry keys. Since my post, we have decided to extract the COM info from the problem dlls manually and add them into the project file. This is not a good solution as our developers tend to change COM stuff without telling the install engineers. We usually find out during QA testing that the product is not working a 100% because we werent told about the changed/ added registry entries and therefore did not update the hard coded registry info in the project file.

I'm really curious to know how other people deal with changing COM info. A while back I used a batch file to extract COM info to .reg files from all our dlls using cmd line regspyui. Then removing hard coded paths from the reg files and making them relative. Each component would load the registry from the .reg file. this was prone to errors and if any dll had same key but different value assigned to it, it would cause errors in the building of the installer.

Basically, it appears that no matter what approach we take we are screwed.

yann

[Jeweller]

MichaelU wrote:
One other comment, because it's not clear from the post whether this happened: ideally most COM registration information will be separated out and put into semantic tables like the Class or ProgId table, and thus the registry keys they represent would not be put into the Registry table. Did you see if the information you know is missing was accounted for in one of the COM tables?

Hello, Michael.
I have the same problem with InstallShield 2008. When I use the RegSpyUI.exe the exctracted registry keys are different than thouse which are written to the registry with regsvr32.exe. This creates great problem for our team because we have about 80 COM components in our product. We cannot manually add lost registry keys to the InstallShield, because some of them are changed at each build. The COM extraction works well with InstallShield X.
Do your team have any plans to resolve this problem? Can we have a chance to get hotfix for this?

Thanks,
Ivan

[MichaelU]

I understand the frustration with this, as we want this to work smoothly. As Chris said above, there's a fine line between including too little and including too much. Is there any chance someone who has found a missing registry key that they need can put together a sample DLL with no other dependencies so we can add it to our test matrix?

[Jeweller]

MichaelU wrote:
I understand the frustration with this, as we want this to work smoothly. As Chris said above, there's a fine line between including too little and including too much. Is there any chance someone who has found a missing registry key that they need can put together a sample DLL with no other dependencies so we can add it to our test matrix?

Where can I upload it?

Thanks,
Ivan

[Colbey]

I have had similar problems with C# dlls. Specifically the problem was that the registry entries created by the ComRegisterFunctionAttribute function were not extracted, I believe this is because they are ignored by regasm /regfile. I worked around it by manually adding the missing keys to the component, but its not a good solution as I often don’t realise keys are missing till QA report a bug.

[MichaelU]

Jeweller wrote:
Where can I upload it?

If you can email it to murman@macrovision.com that would be great. If that fails, just email me without the attachment so I can set up an ftp upload. Alternately if you can host it, just send me a URL.

Colbey: While .NET COM Interop is somewhat related in terms of machine changes, the limitations of regasm are not related to our COM Extraction problems, as the mechanism is completely separate.

[Colbey]

MichaelU wrote:
Colbey: While .NET COM Interop is somewhat related in terms of machine changes, the limitations of regasm are not related to our COM Extraction problems, as the mechanism is completely separate.

I realise it uses a different extraction method, but ultimately the registry info added to the msi by InstallShield is incomplete because of it so I thought I would mention it.

[RvHaandel]

Hi everyone,

In our company we are working with Installshield 10.5 premier. We never had big problems with that since a few weeks ago.

We switched over from Visual Studio 2003 to Visual Studio 2005. Since then we receive this warning during the build of our installs: ISDEV : warning -4354: The build was unable to extract COM information from the file

Our software won’t run anymore because of this...

Does anyone have a solution for this? Or maybe a patch or something?

Thanks in advance!

yann.bertaud wrote:
All,

I have a found a major problem with installshield 2008. Our product uses a lot of COM registry stuff in it's dlls. As such we depend on IS to extract all COM from the dlls at build time. We thought this was reliable, unfortunately it is not. I have run into this a few times now with several different dlls in our product.

As a test i tried the following:
1. use regspyui to extract the COM from the dll. end up with a .reg file that appears complete.
2. in installshield, use the component wizard to add same DLL and turn on Extract COM immediately. Look at the registry for the newly added component. Some of the registry info is missing.
3. again in installshield, use the component wizard and add the dll, this time turn off extract COM immediately.
4. in the component view, turn on Extract COM at build.
5. Build the installer. Open the resulting MSI in installshield. Inspect the registry for the component.

Result: same keys are missing as in step 2.

Am wondering if any one has run into this? if so, did they come up with a solution? this is making us really question the reliability of installshield with regards to COM info and makes us understand why we have been having so many problems with our installer.

thanks

Yann

[yann_bertaud]

do you have visual studio 2005 or the vc 2005 redistributables installed on the machine where you are building the installer, if not, you need to.

yann

[RvHaandel]

Thanks for the tip, I allready installed those vc2005 redistributables.

yann.bertaud wrote:
do you have visual studio 2005 or the vc 2005 redistributables installed on the machine where you are building the installer, if not, you need to.

yann

[RvHaandel]

Today I changed the registry key:

HKEY_CURRENT_USER --> Software --> Installshield --> RegSpy
--> UseAPIRegistryHooks RegDWord :: 0x000001

to:

HKEY_CURRENT_USER --> Software --> Installshield --> RegSpy
--> UseAPIRegistryHooks RegDWord :: 0x000000


That seems to have changed a lot, can anyone explain me what this exactly does?

Let's hope that this is the solution...... :confused: