- You specify custom CAB names (by editing the ISFeatureCabName column of the custom InstallShield Feature table).
- You specify the “One .cab per Feature” option on the Custom Compression Settings dialog of the Release Wizard.
- You sync file IDs with a previous build using the “Previous package” option on the Advanced Settings dialog of the Release Wizard.
If you do build under the scenario described above, then you should be aware that the options appear to be mutually exclusive and the custom CAB names you specified will NOT be generated correctly by InstallShield at build time.
Below is a description of the problem I reported to Acresso support yesterday (incident #SIOA-000140045):
I have a serious problem with the IsCmdBld.exe in InstallShield 2009 Premier that I need a fix for ASAP.
We are in the process of upgrading our build environment to use IS 2009 to build our primary application installation and are seeing different behavior during the build between the IsSABld.exe we used with previous versions of IS (both IS 12 Premier and IS 2008 Premier) and the behavior seen using IsCmdBld.exe in IS 2009 Premier.
Our primary application installation is a very complex and large MSI installation. Since we must control the names of the CAB files we generate at build time, we use the InstallShield Direct Editor to modify the Feature table in the InstallShield source project and specify a different CAB name for each defined feature (using the ISFeatureCabName field). Using the Release Wizard, we also set the Release Configuration to 'Custom' and select the "One .cab per Feature" option ("Custom Compression Settings" dialog of the Release Wizard). In addition, we specify the fully qualified path and name of a previous MSI package build (by setting the "Previous package" option on the "Advanced Settings" dialog of the Release Wizard. The only other configuration information that may be relevant to this issue is the fact that we have multiple merge modules in the project and each defined feature has one or more merge modules associated with it (no merge module is associated with more than one feature).
When we build the installation (with NO CHANGES other than upgrading the project to IS 2009 schema format) using the IsCmdBld.exe command line utility from IS 2009 the CAB files are not generated correctly. In other words, the files associated with feature A are not being placed into the CAB file specified in the ISFeatureCabName for feature A. However, if I remove the option to point the build to a previous package and then build the project then the CAB files are generated correctly (the files associated with feature A are being correctly placed into the CAB file specified in the ISFeatureCabName for feature A.
In other words, the options to specify the CAB file name for each feature (ISFeatureCabName column of the Feature table) and the Release Wizard option for Patch optimization ("Previous package" option) ARE MUTUALLY EXCLUSIVE IN IS 2009.
I have confirmed this behavior by building under the different scenarios described below:
- Build A: IS 12 project file, one .cab per feature enabled, custom CAB names specified in Feature table, previous package path specified, and IsSABld.exe used to build the project.
- Build B: IS 12 project file, one .cab per feature enabled, custom CAB names specified in Feature table, previous package path NOT specified, and IsSABld.exe used to build the project.
- Build C: IS 2008 project file, one .cab per feature enabled, custom CAB names specified in Feature table, previous package path specified, and IsSABld.exe used to build the project.
- Build D: IS 2008 project file, one .cab per feature enabled, custom CAB names specified in Feature table, previous package path NOT specified, and IsSABld.exe used to build the project.
- Build E: IS 2009 project file, one .cab per feature enabled, custom CAB names specified in Feature table, previous package path specified, and IsCmdBld.exe used to build the project.
- Build F: IS 2009 project file, one .cab per feature enabled, custom CAB names specified in Feature table, previous package path NOT specified, and IsCmdBld.exe used to build the project.
In all scenarios specified above EXCEPT "Build E", the CAB files are correctly generated during the build. In other words, in each of the scenarios EXCEPT "Build E", the files associated with feature A are correctly placed into the CAB file whose name is specified in the ISFeatureCabName column of the Feature table.It is absolutely critical that this be fixed or we cannot use IS 2009 without completely redesigning our MSI installation packaging.
3 comments:
Do you know of any known issues with IS2009 and prerequisites for .net framework 3.5 sp 1? I have loaded IS2009 SP2 and the fixes for .NET Prerequisites and MSI Setup Prerequisites. However, when I build an install that has 3.5 framework as a prerequisite and install it to a machine with 3.5 SP1 installed, I get an error stating "Microsoft .NET Framework 3.5 needs to be installed for the installationto continue." Any ideas?
I am not an Installshield "basher", but this is the truth: whenever I worked with Installshield 7 back in the day, I found AT LEAST one major bug per feature of the tool I used.
As I have worked with newer versions of Installshield things have gotten a bit better, but there are still lots of features in Installshield that are not working properly.
I have done lots of work with Wise as well, and I can guarantee you that Wise is less buggy than Installshield. Just the facts.
In my opinion Installshield really needs to improve things if they are to survive in a world where WIX and other deployment solutions are available for free - with LESS bugs!
Hi,
We ran across your website and i read it more interesting, thank you for the ideas you shared i learn a lot from it. We'll come back often.
Once again, thank you very much!
Regards,
Oceans Green
Post a Comment