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.
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.
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?
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?
