- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- ISDEV : fatal error -6040: Internal build error
- 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
Hi all,
I've recently come across this error using Installshield 2015 when attempting to build installers that are supposed to support multiple languages. Does anyone have any information on what is going on with this error? I've trawled the forum and knowledge base, and found a reference to this here , but there seems to be no more information on this.
The error disappears and the installer build is successful when I only have one language selected in the release tab - however, this is not a feasible solution, as the installers I am working on need to support up to 16 different languages.
I have attempted building the installers using Installshield 2019, but this has not solved the problem. I have asked our IT to whitelist our build and C:\Program Files (x86)\InstallShield\2015 directories from the Trend Officescan, and that has not solved the problem. Other than disabling Trend (not really an option here), or using another installer solution, has anyone else encountered this issue?
It's worth noting that this only became a problem early this week, after what I suspect was a Trend update.
Thanks in advance for any possible help with this!
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
I found a solution to this, after a bit of a journey. Hopefully, this will help anyone else who comes across this issue. Disabling our anti-virus tools did not help in this scenario, though it was good to rule them out as the issue.
TL:DR - Ensure that you have set your Product Version Number.
Explanation:
We recently made some changes to our build process - one of these changes was to inject the product version into the installer at build time. Long story short, this resulted in the product version field being wiped out in the .ism file.
Turns out that even though the Product Version Number field is a required field, InstallShield does not give any warnings about this, and actually will build successfully if only one language (the default) is active in the UI Languages fields on the Release tab. As soon as additional languages are selected, the build process is going to fail, as the resource gathering step of the InstallShield build process cannot deal with null/empty strings in the Product Version Number field. I did some further poking around this, and wiped out the ProductName field (for science!). InstallShield does actually warn that this is a required field in this instance, but still builds successfully. This seems fairly inconsistent.
I'm hoping that this can save any other InstallShield users from the pain of figuring this out. As it stands, the documentation around Error 6040 is non-existent, there is nothing in the knowledge base about it, and the InstallShield compiler will not warn you if your product version number is blank. I hope that the InstallShield Developers can either deal with this in their code to give users better feedback, or at least update the knowledge base!
It's also worth noting that this is a problem in InstallShield 2015 and 2019 (part of my process was to try a more recent version of InstallShield), so I suspect that this is an issue across all versions of InstallShield.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Hi @KWicks
Can you see whether this error can be solved by excluding the ism, msi and mst extensions from the scanning software, as per the below KB article:
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Hi @banna_k ,
Thanks for your response! We'll give this a go. I'm not going to be able to confirm if this has fixed our issues immediately, as our IT who has the permissions to update our Trend is in a different timezone from myself, unfortunately.
I'll update here as soon as I know if this has worked. Thank you!
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
@banna_k ,
Unfortunately, your suggestion hasn't solved the issue. Do you have any other suggestions we could try?
Thanks!
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
I found a solution to this, after a bit of a journey. Hopefully, this will help anyone else who comes across this issue. Disabling our anti-virus tools did not help in this scenario, though it was good to rule them out as the issue.
TL:DR - Ensure that you have set your Product Version Number.
Explanation:
We recently made some changes to our build process - one of these changes was to inject the product version into the installer at build time. Long story short, this resulted in the product version field being wiped out in the .ism file.
Turns out that even though the Product Version Number field is a required field, InstallShield does not give any warnings about this, and actually will build successfully if only one language (the default) is active in the UI Languages fields on the Release tab. As soon as additional languages are selected, the build process is going to fail, as the resource gathering step of the InstallShield build process cannot deal with null/empty strings in the Product Version Number field. I did some further poking around this, and wiped out the ProductName field (for science!). InstallShield does actually warn that this is a required field in this instance, but still builds successfully. This seems fairly inconsistent.
I'm hoping that this can save any other InstallShield users from the pain of figuring this out. As it stands, the documentation around Error 6040 is non-existent, there is nothing in the knowledge base about it, and the InstallShield compiler will not warn you if your product version number is blank. I hope that the InstallShield Developers can either deal with this in their code to give users better feedback, or at least update the knowledge base!
It's also worth noting that this is a problem in InstallShield 2015 and 2019 (part of my process was to try a more recent version of InstallShield), so I suspect that this is an issue across all versions of InstallShield.