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: IS2010 SP1: "ISDEV : error -6259: Internal build error" after adding a component.
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
‎Oct 19, 2009
01:11 PM
IS2010 SP1: "ISDEV : error -6259: Internal build error" after adding a component.
Adding a simple component to my installation project generates "ISDEV : error -6259: Internal build error". Changing the installation from Compressed to Uncompressed makes the error go away, but is NOT an acceptable solution.
The installation builds with 0 errors/warnings until "Data1.cab built" and then fails before "Files built" according to the log file.
Since we are close to product release it is critical to find a solution and I much appreciate any help on solving the problem.
The installation builds with 0 errors/warnings until "Data1.cab built" and then fails before "Files built" according to the log file.
Since we are close to product release it is critical to find a solution and I much appreciate any help on solving the problem.
(7) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 19, 2009
02:05 PM
Often you can get further information about what exactly is failing by getting a verbose build log. To do this, run a command-line build with the /v argument. Something like ISCmdBuild.exe /v /p"Path\To\Project.ism" ...
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 20, 2009
09:21 AM
MichaelU,
Thanks for your advice.
Unfortunately the error does not show up when building from command line.
Is it possible to set verbose logging when building from the GUI?
Thanks,
Svend
Thanks for your advice.
Unfortunately the error does not show up when building from command line.
Is it possible to set verbose logging when building from the GUI?
Thanks,
Svend
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 20, 2009
04:44 PM
This error is related to digital signing...To narrow it down, can you reproduce this in a new project with one feature and a couple of components? After the build is done, can you look at the MsiDigitalCertificate table and see if any records exist?
Anything unusual (non ansi characters) in the path location name where the project is stored or in the project name or file names being signed?
Anything unusual (non ansi characters) in the path location name where the project is stored or in the project name or file names being signed?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 21, 2009
10:10 AM
Dear Marwan,
Unfortunately this error is not always reproduceable. I have only seen it when doing the build from the GUI and never from the command line on the same machine.
I have changed the daily build (command line) to use verbose logging (/v) in case it should fail. It would be nice also to use verbose logging when building from the GUI. Is that possible?
The installation is quite large and I am afraid that I am running into some kind of ressource problem. The good thing is that the daily build is still running without failing.
Regards,
Svend
Unfortunately this error is not always reproduceable. I have only seen it when doing the build from the GUI and never from the command line on the same machine.
I have changed the daily build (command line) to use verbose logging (/v) in case it should fail. It would be nice also to use verbose logging when building from the GUI. Is that possible?
The installation is quite large and I am afraid that I am running into some kind of ressource problem. The good thing is that the daily build is still running without failing.
Regards,
Svend
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 22, 2009
02:23 PM
Several installations are being built during the process, butonly the biggest one fails some time.
Could the problem be caused by a bad connection to the Verisign time stamp server which is used during the signing process?
Any idea how to find out exactly what fails during the digital signing?
/Svend
Could the problem be caused by a bad connection to the Verisign time stamp server which is used during the signing process?
Any idea how to find out exactly what fails during the digital signing?
/Svend
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 23, 2009
02:47 PM
Look at the documentation here http://msdn2.microsoft.com/en-us/library/aa387764.aspx They recommend using MakeCat for any files larger than 300Megs and mention low system resources...I think loading the whole file into memory is needed in order to verify the signature and that sometimes fails due to low system resources...
Also, here's a KB about verification issues on Win2K3: http://support.microsoft.com/kb/938759
Which OS are you building on? and are you using a .pfx or a .spc file to sign?
If you have any large cab files you are signing, consider splitting those into smaller ones.
Also, here's a KB about verification issues on Win2K3: http://support.microsoft.com/kb/938759
Which OS are you building on? and are you using a .pfx or a .spc file to sign?
If you have any large cab files you are signing, consider splitting those into smaller ones.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 02, 2009
10:21 AM
I am building on XP SP3 and use .pfx to sign.
(Un)fortunaly the problem is not always reproduceable, but now I know what to look for. However it would be nice with more detailed error information in the log file than just "Internal error".
Thanks,
Svend
(Un)fortunaly the problem is not always reproduceable, but now I know what to look for. However it would be nice with more detailed error information in the log file than just "Internal error".
Thanks,
Svend