ProgIds missing in MSI with VS2005-compiled COM components

[Gunsun]

I have just compiled our product successfully with VS2005 but the application now apparantly fails to register correctly and thus it will not even start up.

When I compare the MSI file containing the files built with VS2003 with the MSI file containing files built with VS2005 I can see that I am now missing almost 300 ProgId entries in the MSI ProgId table. I'm using the very same InstallShield project in both cases. I'm using "COM Extract at Build".

How could a COM dll compiled in VS2003 and VS2005 be different from a InstallShield point of view when it comes to extracting COM information during build time?

I'm using InstallShield 10.5 Premier Edition.

Any ideas, tips, solutions or workarounds??

[Gunsun]

It is a problem with the InstallShield COM extraction component. It treats COM components built with VS2003 and VS2005 differently.

I can reproduce the behaviour with the tool "InstallShield Simple COM Extraction" (RegSpyUI.exe).
I get the COM information when I use the tool to extract COM info from the component built with VS2003. When I use the tool to extract COM info from the very same component built with VS2005, no COM info is being returned.

Obviously the same problem exists with the StandAlone Build version of the extraction tool (SARegSpy.exe).

MacroVision FlexNet InstallShield, please help me out here!!!!

[MichaelU]

Your wish happens to have some very good timing! We were looking into this on other reports, and we have an experimental replacement you can try. It's seen only limited internal testing against our 11.5 code base, and hasn't gone through any real QA process, so it's at your own risk and all that. That said it should work with 10.5 and maybe as far back as DevStudio 9 as well.

The attached zip has two files that go into your [INSTALLDIR]system folder after you backup the existing files of the same name (C:\Program Files\InstallShield 10.5\System or whatever) and two registry files - one to enable the new method, and one to turn it off. We'd appreciate any feedback you have as to whether this helps, solves, hurts, or fails to impact COM extraction on any kind of DLL, as we're looking to include this in a future release.

[Gunsun]

Thank you.

I tried replacing IsRegInj.dll in my "InstallShield 10.5 StandAloneBuild" folder, but I guess I will need a matching SARegSpy.exe file as well to see any result.

Could you please send me a new SARegSpy.exe and I'll be happy to try it out on all our installation projects.

StandAloneBuild is actually our main installation building tool. Since we have so many projects to build on a daily basis it is very neat to have dedicated build machines for this purpose.

Do you think the new runtime manifests for ATL80 etc that are built into the COM components by default in VS2005 is causing the problem with RegSpy?

[MichaelU]

Many things are possible for why COM extraction fails more frequently. We've got some general ideas, but not tracked anything down yet. Anyway, here's the SARegSpy.exe - I hope it does the trick.