View Full Version : COM Extraction not working

07-12-2007, 09:29 PM
Please excuse my ignorance on COM Extraction.

I have a DLL that needs com extraction. When I build my project I am getting the following warnings:

ISDEV : warning -6248: Could not find dependent file Hcn.EftposEclaim.Utils, or one of its dependencies of component Hcn.EftposEclaim.Messages.dll_TEST
ISDEV : warning -6248: Could not find dependent file Hcn.Translator, or one of its dependencies of component Hcn.EftposEclaim.Messages.dll_TEST
ISDEV : warning -6248: Could not find dependent file nunit.framework, or one of its dependencies of component Hcn.EftposEclaim.Messages.dll_TEST

The first two dependencies mentioned are in fact listed and installed to the same directory as the Hcn.EftposEclaim.Messages.dll_TEST component.
I do not know what the thrid file is at all!

I assume the com won't extract because of the missing dependencies.

When I install this build onto a test environment, the com information has not been extracted (no shock seeing as it wasn't extracted in the build either). However, if I run regasm manually, the com extracts no problems.

What has gone wrong? Why can I do this manually but I can't seem to get the automated installshield feature working?

Christopher Painter
07-12-2007, 09:38 PM
If you try doing COM EXtract on A.DLL and A.DLL has a dependency on B.DLL and B.DLL is not in the LoadLibrary path, it will fail because the DllRegisterServer() function in A.DLL will never run.

Try running Depends.exe to identify your missing libraries. Also consider extracting the COM data of your key file once instead of at build time to prevent upgrade problems. Extract at build should be reserved for situations where you only support major ( or no ) upgrades and your interfaces frequently change in your COM servers.

Christopher Painter
07-12-2007, 09:40 PM
Actually I jus noticed the regasm reference.... don't use COM extraction. Set the components .NET Scan At Build property to Properties Only and the .NET COM Interop property to Yes.

07-12-2007, 10:04 PM
Fabulous instructions. Thanks! All working.

Can you possibly explain what this bit means please?
.NET Scan At Build property to Properties Only
.NET COM Interop property to Yes

Just briefly if that's possible, or send me somewhere I can read about it? I like to understand what I've changed, it's the only way to learn.

Christopher Painter
07-13-2007, 11:11 AM
That's a lot of ground to cover. :cool:

COM and .NET COM Visible are somewhat different concepts that result in the ability to instantiate a COM server. COM extraction uses LoadLibrary and then call's the DLL's DllRegisterServer() function to spy on what the function would have done. Then it authors MSI tables to mimic this behavior.

But a VB.NET/C# assembly isn't WinPE code so it can't be directly called like that. RegAsm does a similar concept only it uses reflection to determine the COM registration needs of the ComVisible(true) class. InstallShield has written a similar method but instead of writing to a reg file, it writes directly to the MSI tables to teach MSI how to register your assembly for interop.

These methods are better then calling regsvr32 or regasm because now MSI understands your COM server / Interop Class better and can better install, uninstall and repair it.

Rob mensching has a good article explaining all of this:


Buried in the XML you'll see this component element:

<Component Id='TestAssemblyProductComponent' Guid='G-U-I-D-Here'>
<File Id='TestAssemblyProductFile' Name='assembly.dll' Assembly='.net' AssemblyRegisterComInterop='yes' KeyPath='yes' DiskId='1' />

You'll note that essentially he's doing the same thing as InstallShield. He's setting the File@Assembly to .NET ( equivilant to Properties Only ) the File@AssemblyRegisterComInterop to Yes which is the equivilant to True.

Of course the reason I like InstallShield is I don't have to memorize all of this XML stuff. I just right click | new component, add file, set keyfile, set two dropdowns and move on........

Tim Mayert
07-13-2007, 01:05 PM
I am also having issues extracting COM information from IS 2008. There seems to be some issue with this that I consider a bug.

I have the same project opened in IS 2008 and IS 12. I perform the COM Extraction on the same component and in IS 12 everything is extracted correctly, but in IS 2008 it extracts everything except for the Type Libraries.

Now these are all on the same machine and all dependency files are where they should be, otherwise the IS 12 component COM Extraction would have failed.

So I manually entered the missing Type Libraries in the IS 2008 project, but as soon as I do a refresh COM information then the Type Libraries entry will be removed.

So what is IS 2008 missing that works for IS 12????


Christopher Painter
07-13-2007, 01:25 PM
Maybe the filters.xml is getting in the way. Have you tried C:\Program Files\Macrovision\IS2008\Support\RegSpyUI.exe?

BTW, Mike Marino is the man when it comes to this subject...

Tim Mayert
07-13-2007, 01:38 PM
Actually after a little more looking around I found the thread about Microsoft stating the best practices was to place the Type Libraries information in the Registry Table instead of the Com Extraction table. So I checked and sure enough the Type Libraries information was there.

I have not yet tested the install, as I am only doing a side by side comparison to look for differences and therefore that was why I noticed the difference when the Type Libs information did not show up.

When I am done the whole install then I'll have it tested on a clean machine to see if the Com Extraction does still work correctly.


Christopher Painter
07-13-2007, 01:58 PM
Microsoft or Rob Mensching? ( RobMen != Windows Installer Team )

FWIW ICE33 still says you should use the TyleLib table over the Registry table. Rob disagrees and InstallShield is caught in the middle wondering..... well I suppose I shouldn't speak for InstallShield.

Going either way won't break Vista Certification so I really don't care any more. Specially since I'm all .NET and I don't have to worry about COM anymore anyways...

Tim Mayert
07-13-2007, 02:03 PM
Well if it works the default way in IS 2008 then fine, but if not then I can get back to the old method by using the instructions in the KB articale Q113259

So hopefully things work properly and I do not have to go an change things to make it work....

07-16-2007, 09:50 AM
Microsoft or Rob Mensching?Both, in this case. See the TypeLib table MSDN topic (http://msdn2.microsoft.com/en-us/library/aa372092.aspx)'s remarks. You're right that ICE33 hasn't been updated for this yet, and I certainly can't say if it will be.

Christopher Painter
07-16-2007, 10:08 AM
Thanks for pointing that out. The latest COM best practices all become a blur after awhile. That's why I'm glad I have InstallShield.

Tim Mayert
07-17-2007, 01:11 PM
Off the topic question Chris, but have you heard anything about the new installer package InstallAware?

I am doing research in to other install packages and I am basically only comparing the most popular ones, which are InstallShield, Wise and then I also found InstallAware and Ghost.

Do you happen to have an opinion on which is the best to work with, which is good for administation push, less error prone, ease of use, ...etc?

If you have an information about these could you let me know?