How to change product code programmatically

Question

I have created bat file for automatic build. It's create installer of my product. But problem is that before run automatic build script I have to change product code manually from install shield. So, is there any way to change product code automatically ? because everything is automatic except product code.

Swinge

What version of Installshield are you using? – Roque

Are you using MSBuild or ISCmdBld.exe? – Disarmament

I am using install shield standalone build – Swinge

@SteinÅsmul: insall shield 2013 – Swinge

Answer 1

As Phil says you can do this via the COM automation interface for Installshield, but there are also other ways as explained here: Installshield Build Automation.

Essentially:

1. The link above shows a small sample of how to use the standalone build executable ISCmdBld.exe - which you might already be using.

   • Something like: "[PATHHERE]ISCmdBld.exe" -p "MyInstaller.ism" -r SingleImage -y "1.0.0.13" -z ProductCode=%guid%.
   • Do check the above link out - I have never used ISCmdBld.exe opting for COM automation instead.

2. The linked answer also explains how to use msbuild, read Urman's answer.

3. Finally you can use the COM automation interface and a VBScript (or Javascript?), and I have added a small sample below for how this can work.

I don't have Installshield 2013 available, but here is a very rough sketch of how you can automate the latest version 2016 via COM automation using a VBScript:

' On Error Resume Next

Set isproject = CreateObject("ISWiAuto23.ISWiProject")
isproject.OpenProject "C:\InstallShield 2016 Projects\TestProject.ism", False

Set isproductconfig = isproject.AddProductConfig("MyNewProduct_1.0.16")
isproductconfig.ProductName = "MyNewProduct_1.0.16"
isproductconfig.ProductVersion = "1.0.16"
isproductconfig.ProductCode = isproject.GenerateGUID
' lots of properties to set, the above should normally suffice I think...

Set isrelease = isproductconfig.AddRelease("MyNewRelease_1.0.16") 
isrelease.Compressed = True
isrelease.SetupEXE = True
' lots of properties to set...

' Save and build project
isproject.SaveProject ' For some reason the project won't save properly after it is built
isrelease.Build
isproject.SaveProject

' Report error status
WScript.Echo "Number of Build Errors: " & CStr(isrelease.BuildErrorCount)
WScript.Echo "Number of Build Warnings: " & CStr(isrelease.BuildWarningCount)

isproject.CloseProject

This script wasn't tested that thoroughly, and weirdly, the new product configuration and release are not saved unless you save before triggering the build. It might be something simple I have mixed up - or it might be a bug in the tool (it wouldn't be the first one).

Take it for what it is, let's hope it gets you going to work out the wilburys on your own (bugs). I think it might run if you change ISWiAuto23.ISWiProject to IswiAuto20.ISWiProject to match the Installshield 2013 COM server version.

Crucially, you must run the VBScript from a 32-bit CScript.exe / WScript.exe (don't ask me why). Just put a shortcut to C:\Windows\SysWOW64\cscript.exe on your desktop for testing, and drag and drop your script onto it, or better yet, open a command prompt and go to C:\Windows\SysWOW64 (believe it or not this is the 32-bit folder - and the System32 folder is 64 bit (!) - only in Windows!) and then type cscript.exe [FullPathToVBScript]. Obviously remember to close your ISM file in the Installshield GUI before running the script.

I like the fact that you can save the new release and product config inside the *.ism file so you have a record of compiled releases. I am not sure what ISCmdBld.exe does.

Selftaught

Dozens of languages support COM. Perl, Python, NodeJS, C++/C#... yes only 32bit is supported. :( I would simply use IsCmdBld.exe -z Property=Value without all that complexity. (That said I'm really an MSBuild advocate so I'd using a Property Function to generate the GUID and pass that into the build using PropertyOverrides. – Disarmament

Probably a good idea to try MSBuild. I would try it, if I had a chance. As to the COM languages: my experience is that you get total X-files problems unless you use a language that is well tested with the COM object model in question. I have had serious strangeness with Javascript and the Windows Installer object model for example (all MSI SDK samples are in VBScript - so we know what they tested with originally). For all I know Javascript could be better for Installshield. Or C# might be well tested as well, no way to tell. I have heard people struggle a lot when trying Perl with COM. – Roque

Answer 2

I think you are supposed to use the InstallShield automation for this kind of thing, such as the ISWiProductConfig object that exposes the ProductCode of the MSI you're building.

Louanne