This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Re: ISDEV : fatal error -6002
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 17, 2014
06:59 AM
ISDEV : fatal error -6002
Hello all,
I maintain several deployment projects and the infamous -6002 error usually failed about 90% of the build attempts, but now it persists.
It fails in the GUI and SAB. There's no Access stuff used and disabling the virus scanner doesn't do anything.
It sees to generate the MSI file but fails anyway:
ISDEV : fatal error -6002: Error while attempting to run the custom build setup for objects.
110: Error opening
It is driving me crazy, if there's someone who can shed some light on this that would be great 😄
Thanks in advance!
(IS2013)
I maintain several deployment projects and the infamous -6002 error usually failed about 90% of the build attempts, but now it persists.
It fails in the GUI and SAB. There's no Access stuff used and disabling the virus scanner doesn't do anything.
It sees to generate the MSI file but fails anyway:
ISDEV : fatal error -6002: Error while attempting to run the custom build setup for objects.
110: Error opening
It is driving me crazy, if there's someone who can shed some light on this that would be great 😄
Thanks in advance!
(IS2013)
(6) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 24, 2014
07:52 AM
Anyone ? Sadly I was expecting very few replies as this error is one of the vaguest to get.
I'm seriously considering ditching IS2013 for something else, even considering it's a ton of work to re-write all the installers.
Hopefully someone at Flexera can at least explain what's going wrong.
I'm seriously considering ditching IS2013 for something else, even considering it's a ton of work to re-write all the installers.
Hopefully someone at Flexera can at least explain what's going wrong.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 24, 2014
12:10 PM
Build error -6002 is tied to the use of older/legacy style InstallShield objects in an MSI type project. These objects are essentially merge modules that have custom build code that runs during project build. All new redistributables shipped with InstallShield are provided in the form of normal Windows Installer merge modules or InstallShield prerequisites. No new InstallShield objects have been shipped with InstallShield since around the InstallShield X release as, generally speaking, they do not provide much additional value. InstallShield 2013 only contains the following InstallShield objects that are considered legacy redistributables: Jet 4.0, DirectX 9.
The best way to troubleshoot this issue would be to determine if the project(s) encountering this build error contain an InstallShield Object. In the Redistributables view, sort by the Type column and then scroll to the InstallShield Object type. If any of these are included, remove them from the project and attempt to build again. The project(s) should no longer encounter the -6002 error as no redists in the project are using custom build code. If at all possible, it is recommended that these objects no longer be included. All of these objects are over 10 years old and the technologies they install are now included as part of all versions of Windows currently supported by InstallShield. If not, you may try re-adding the objects to the project to see if they will then build successfully.
The best way to troubleshoot this issue would be to determine if the project(s) encountering this build error contain an InstallShield Object. In the Redistributables view, sort by the Type column and then scroll to the InstallShield Object type. If any of these are included, remove them from the project and attempt to build again. The project(s) should no longer encounter the -6002 error as no redists in the project are using custom build code. If at all possible, it is recommended that these objects no longer be included. All of these objects are over 10 years old and the technologies they install are now included as part of all versions of Windows currently supported by InstallShield. If not, you may try re-adding the objects to the project to see if they will then build successfully.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 25, 2014
03:47 AM
Hi Josh,
Thanks for your reply. The project contains 3 Redistributables: .NET 4.0 Full, Visual C++ 2010 SP1 x86 and x64. There's only one entry of type "InstallShield Object" in the list, DirectX 9, and it's not selected. I deselected the 3 entries to see what would happen, but the -6002 still occurs after that.
Regards,
Vincent
Thanks for your reply. The project contains 3 Redistributables: .NET 4.0 Full, Visual C++ 2010 SP1 x86 and x64. There's only one entry of type "InstallShield Object" in the list, DirectX 9, and it's not selected. I deselected the 3 entries to see what would happen, but the -6002 still occurs after that.
Regards,
Vincent
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 25, 2014
01:09 PM
If you open the ISMergeModule table in the Direct Editor in the project(s) encountering this build behavior, are there any records present? This table should be empty as the redists you listed as included in your project are prerequisites and not merge modules (or objects). If there are any records present here, what are they?
- Is this behavior occurring with any project or only some projects?
- If you create a new test MSI project, does the behavior occur with that if it contained one feature, one component, and one file?
- Would it be possible to get a verbose build log from one of these projects where this error occurs?
- Is this behavior occurring with any project or only some projects?
- If you create a new test MSI project, does the behavior occur with that if it contained one feature, one component, and one file?
- Would it be possible to get a verbose build log from one of these projects where this error occurs?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 28, 2014
02:43 AM
Hi Josh,
The ISMergeModule table is empty.
This problem doesn't occur in all our projects. The more basic projects build just fine.
I'll send you the verbose build log by PM.
Regards,
Vincent
The ISMergeModule table is empty.
This problem doesn't occur in all our projects. The more basic projects build just fine.
I'll send you the verbose build log by PM.
Regards,
Vincent
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 30, 2014
03:53 PM
Unfortunately the log doesn't provide much indication of what might be occurring before or after the custom object build code that could be triggering the error.
Reviewing our code for custom object processing, it is still possible for a -6002 error to occur without using custom objects. The custom object build is wrapped between an attempt to close the target MSI file and then reopen the file after the custom object builds have finished. If the MSI fails to close appropriately or fails to reopen, then this error can occur. The code roughly does the following:
- Commit any unsaved changes with MsiDatabaseCommit
- Close the database handle with MsiCloseHandle
-
- Reopen the target MSI database with MsiOpenDatabase in MSIDBOPEN_DIRECT mode
-
If any of the MSI API calls fail for any reason, a -6002 build error will occur. Unfortunately, beyond strange sharing violation issues, we can't say what could be causing these API calls to fail.
To try to determine if and/or why the above procedure may be failing, the projects that encounter this need further testing in an attempt to isolate the issue:
- If a new product configuration and release with default settings are created in these project(s), do the new config/release build without error?
- If the above does not change the error behavior, try turning off all .NET Scan at Build components in the project (set the .NET Scan at Build setting on each component to None) and build again. Does the error still occur?
Reviewing our code for custom object processing, it is still possible for a -6002 error to occur without using custom objects. The custom object build is wrapped between an attempt to close the target MSI file and then reopen the file after the custom object builds have finished. If the MSI fails to close appropriately or fails to reopen, then this error can occur. The code roughly does the following:
- Commit any unsaved changes with MsiDatabaseCommit
- Close the database handle with MsiCloseHandle
-
- Reopen the target MSI database with MsiOpenDatabase in MSIDBOPEN_DIRECT mode
-
If any of the MSI API calls fail for any reason, a -6002 build error will occur. Unfortunately, beyond strange sharing violation issues, we can't say what could be causing these API calls to fail.
To try to determine if and/or why the above procedure may be failing, the projects that encounter this need further testing in an attempt to isolate the issue:
- If a new product configuration and release with default settings are created in these project(s), do the new config/release build without error?
- If the above does not change the error behavior, try turning off all .NET Scan at Build components in the project (set the .NET Scan at Build setting on each component to None) and build again. Does the error still occur?
![](/skins/images/CC38E504FC9E1309DC48ACFEB4925670/responsive_peak/images/icon_anonymous_message.png)