View Full Version : COM-extract at build fails with Internal build error 6017

03-28-2006, 08:53 AM
I have installed IS12 and migrated a number of projects from IS11.5 with no problems.

But when I build my projects I get Internal Build Error 6117 if the project contains components with "Com-extract at build" enabled.
If I disable "Com-extract at build" for all components the build completes successfully.

Mike Marino
03-28-2006, 11:34 AM
Can you try registering IsRegSpy.exe?

C:\Program Files\Common Files\InstallShield\IsRegSpy.exe /regserver

If that does not work, can you let me know what Operating System you are running under?

Dennis Marks
03-28-2006, 12:01 PM
We have similar problems with COM registration. I took our Package that has moved up through the install packages and we are getting 4354 error code. Unable to extract COM information on all our DLL's that we have COM EXTRACT at Build turned on for.

I did go through the IDE release wizad and walked down through all the options that we have. Not I also got a .net framer redist failure 6247 even after I downloaded it. This is on Windows XP SP2 with all the updates. I can run regspy, regsvr32 our internal registration on this box and all works fine!

Regsvr32 build on the files work fine!

Mike Marino
03-28-2006, 12:07 PM
What OS are you running on, and what tool was used to build these DLLs?

We have a new COM extraction mechanism that is in the beta, just not turned on by default.

It fixes problems extracting COM information on 2003, and Vista. It also fixes problems extracting COM information from files built in Visual Studio 2005.

To turn on this new mechanism run the enclosed NewMethod.reg file.

To go back to the old way run OldMethod.reg.

Dennis Marks
03-28-2006, 12:17 PM
Our DLL's our currently being build on WinXP SP2 machines with all critical updates.

Our DLL are C++ DLL compiled with a .net compiler.

There is currently no .net requirements within the DLL's at this time. We are moving towards .net. Note we are not on Visual Studio 2005 either!

This are all Windows Platform. Once we build the DLL required, add in the third party dlls, then they port over with Makewin to Unix and equivelant OS!

Mike Marino
03-28-2006, 12:23 PM
I would try the new mechanism. It has fixed a lot of users' issues. (We have a version that works with 11.5 as well.)

03-28-2006, 01:16 PM
How can I get the version that works with 11.5? We have similar issues with 11.5...



03-29-2006, 08:28 AM
Registering IsRegSpy.exe fixed error 6107 and I am now able to build my project with no errors and warnings. But when I run my installation I get a run-time error which I can not resolve (see attached pulse.zip).

Please give me some advice on how to solve the problem.

I do not know what the registration does, but
HKEY_CURRENT_USER\Software\InstallShield\RegSpyProxy showed up in the registry after the registration. Will IsRegpy.exe then work for other users logging into the machine ?

I am very happy to see that the 81 x "Warning -7105" which were introduced in IS11.5 have disappeared again :-)

Mike Marino
03-29-2006, 09:05 AM

It is used as a registry redirection location for COM extraction.

This key will not effect other users on the machine, since it will be created everytime you run COM extraction.

Mike Marino
03-29-2006, 09:10 AM
It looks like you are getting a 1603 error...Correct?

03-29-2006, 09:10 AM
Any idea why I get the run-rime error ?

Mike Marino
03-29-2006, 12:58 PM
It looks like you are getting a 1603 error...Correct?

03-30-2006, 07:16 AM
The error 1603 was in some way related to the msxml3 merge module.

I solved the problem by using
with its dependencies, instead of using
which is distributed with IS12-Beta.

Other issues:
1) It looks as if setup.exe does not install an upgraded Install Script Engine ?
2) Custom action had a problem accessing file in SUPPORTDIR
3) Problem accessing c:\config.msi - what is it ???

Mike Marino
03-30-2006, 10:42 AM
1. The bulk of the Script engine is installed to a different location now...

(Look in C:\Program Files\InstallShield Installation Information\{Your Product Code})

2. Where is your custom action Scheduled?

3. When did you get this error accessing Config.msi?

We need to look into the MSXML issue. There appear to be two version of this floating around. I will try to get this fixed soon. Thanks for the information.


03-31-2006, 06:17 AM
1) C:\Program Files\InstallShield Installation Information\{My Product Code}) is not created during installation.

2) A message box in my deferred CA with sequence number 5920 says that SUPPORTDIR is assigned to C:\Documents and Settings\slysemose\Local Settings\Temp\{My Product Code}, but the folder does not exist. IS11.5 creates it during setup initialization.

3) Now C:\Config.msi is created during installation. As I remember I only
saw this the first time I executed my IS12 based installation.

I think I have to stop the test now and wait for a beta refresh.

Mike Marino
03-31-2006, 10:33 AM
What project type is your project, Basic MSI with InstallScript Custom Actions, or InstallScript MSI?

In Basic MSI with InstallScript Custom Action, the Engine is not cached on the users system by itself (it is in the cached MSI package).

We need to look into the SUPPORTDIR issue.

We are currently planning a beta refresh at the end of next week.

03-31-2006, 10:41 AM
My project is Basic MSI with InstallScript Custom Actions.

What I noticed was that C:\Documents and Settings\slysemose\Local Settings\Temp\{My Product Code} showed up when tha CA was fired - but without my helper.dll from the binary table.

With a few tricks I actually managed to successfully complete my most
complex installation which seemed to work fine after some smoke testing.

I will be happy to test the beta refresh if a get a notification

Dennis Marks
04-07-2006, 10:46 AM
We have been having issues here with build packages moving forward from anthing lower with msxml3 merge module. Looks like Installshield 11.5 and 12 have a new merge module set which is service pack 5 related and Microsoft has pulled this service pack from the shelf. They are now at SP7 but there seems to be no merge module available. So we have migrated back to SP4 of this merge module in our normal package. I will test and check and see if this was a cause of one of my issues.

04-07-2006, 01:36 PM
I have found the MSXML3 SP7 merge modules at the following location on Microsoft's site:

You will need to download the MSXML3msms.exe file to get them.

These SP7 merge modules will also be included with the Beta refresh build coming soon.

04-10-2006, 04:38 AM
Hello Sheryl,

I have successfully installed the MSXML 3.0 SP7 merge modules in my IS 11.5 environment and started using it.

If you are responsible for the redistribution of merge modules in IS12, I will ask you to include the latest version of MSXML 4.0 and the released version of Microsoft_VC80_*.msm (Visual Studio 2005) - the current merge modules are beta-versions.

Looking forward to the IS12 beta refresh.

Mike Marino
04-10-2006, 10:03 AM
The Visual Studio 2005 msms installed with our product are the released versions (Microsoft_VC80_*.msm).

They do say "Beta" in the Subject area of the Merge Module. Microsoft told me that this was an oversight, and that the "Beta" in the Subject will be removed in a later version.

If you know of a later version, please let me know.

04-10-2006, 02:35 PM
I have added the MSXML 4.0 SP2 merge modules to the product. These files will also be in the beta refesh build.

04-12-2006, 05:36 AM
As a general comment for your QA-process for major updates, I would suggest that you include an update/verification that all inluded merge modules are at latest version.

Regarding "Beta" in the subject field for Microsoft_VC80_*.msm I do not know of later versions, but just wanted to inform you about this.

Thanks for the update to MSXML 4.0 SP2.

Dennis Marks
04-12-2006, 09:39 AM
Another issue is with the GDIPlus which we also use here is one that has an issue with a security vulnerability. IOA-000023845 is an issue I reported as well.

Another one that has issues is the OLEDB21. It does not have the Data file information added into the hash Table entry and this will cause your MSI to go back to source during patching and upgrades. We have filled in the merge module File Hash Table Entry and all works fine for our Patching and upgrarding when using this Merge Module.

Dennis Marks
04-19-2006, 12:39 PM
This is all fine to obtain the latest merge module for major upgrades, but it does break minor/patching issues with the SP4 merge modules. Seems like they are using the same dependency merge modules which are configured differenetly.