InstallShield 2013 Premier and Continuous Integration...

[Superfreak3]

Hi all,

We are going to be moving from our current, scheduled, scripted binary compiles and installation builds to a Continuous Integration model based on TFS Build Server/Controller/Agent/Build Definitions. I'm wondering if there is any information out there regarding how to pull my installation compiles using InstallShield into the mix.

I'm guessing this is going to come via a post build script called from the TFS Build Definition. If anyone out there has some experience, examples, etc illustrating what they've done I would more than appreciate the information.

Thanks!

[Reureu]

I assume you already have your ISM file. I would start by integrating in project in a Visual Studio solution.
This will create an ISPROJ file. This file refers your ISM file, and allows to build your InstallShield project when building your solution (e.g. MyInstallationSolution.sln).

This ISPROJ file can then be tweaked to change MSI properties, override Path variables, add a Merge Module Path... It looks a bit like a VCXPROJ, or a CSPROJ file, with some MSBuild Items and Properties.

Once you have your InstallShield project integrated into your solution, you need to be able to build your solution from the command line with MSBuild:

MSBuild /t:Build /p:Configuration=Release /p:SomeMSBuildProperties=Blabla MyInstallationSolution.sln

To do this, I recommend to launch a Visual Studio 20xx Command Prompt x86 as Administrator.

You can then create your own MSBuild file to build your whole application and your installation solution (e.g. ApplicationBuild.msbuild).

Your build definition will then refer this msbuild file.

You will find a whole section about the integration with Team Foundation Server in the InstallShield User Guide (http://helpnet.flexerasoftware.com/installshield21helplib/helplibrary/TFS-Overview.htm).

Here are some more hints. They only reflect my humble opinion and some people might prefer to do it differently:

• Do create a separate solution for your InstallShield project(s). This allows to isolate your installation solution from other projects that developers are working on. I am not a fan of how the InstallShield integration in Visual Studio creates new components for the new CSPROJ or VCXPROJ we add to our VS solutions.
  
• I don't like how the InstallShield integration in Visual Studio creates new releases in my ISM file when I change the Solution configuration (debug/release...). So I avoid editing my Installation project through Visual Studio. I stick to InstallShield for editing the ISM file.
  
• It might be worth spending time learning how to use MSBuild. How to use properties, items, tasks and targets, etc...
  

[Superfreak3]

First off, thanks for the reply!!

Yes, we have our .ism or maybe I should say we will be creating the .ism for our new product work beforehand.

What I think I might be able to do is create the Build Definition, which will build the needed projects/binaries. I could then create a post build MSBuild script to compile the installation. The .ism template will be created ahead of time so I can either stage the files after build as part of the post build script before compiling the install or I can simply use the project output locations for the installation source paths.

Currently we have the .ism checked into TFS as a file and not part of a project. I guess I could go that route in the future and just call the InstallShield .exe for compile via an InvokeProcess activity in a customized Build Template or script that as well. In short, I guess there are various ways this can be done. I would be curious as to the pros and cons of making the .ism as part of a project for use with MSBuild vs scripting the install build in some way to fire the InstallShield .exe.

I will also be modifying the .ism outside of VS as I'd be more comfortable with that as well. I like to control component/feature/release naming, etc so I don't want VS doing that for me.

[Reureu]

Calling ISCmdBld.exe from our MSBuild script, using an task was our first idea, before we understood that this mechanism was already available thanks to the InstallShield integration with MSBuild.

Here is a bottom-up explanation:
You might notice that the InstallShield setup added the following file: C:\Program Files (x86)\MSBuild\InstallShield\2013\InstallShield.targets
This file contains everything needed to call IsCmdBld.exe with all the required parameters.
You might notice the InstallShield task in this file:

The ISPROJ file I mentioned in my earlier post imports this InstallShield.targets file.
Your ISPROJ also refers your ISM file, and this ISPROJ is part of a VS solution.

This mechanism allows to call IsCmdBld.exe when building your solution.

Now let's summarize it, this time from top to bottom:

• You call MSBuild /t:Build /p:Configuration=Release MySolution.sln
  
• MSBuild builds your projects in your solution.
  
• MSBuild executes the "Build" target of your ISPROJ.
  
• Your ISPROJ will execute the "Build" target defined in the "InstallShield.targets" file. This will call IsCmdBld.exe and build your Installation package.
  

Pros:

• You don't need to worry about what executable needs to be called, and how to call it.
  
• You don't need to worry about the path of IsCmdBld.exe (which might vary on a build server where only IS Standalone Build is available)
  
• When you upgrade to the next release of InstallShield, all you need to do is:
  
  
  
  • Upgrade your ISM file (which you do anyway).
    
  • Change the path of the InstallShield.targets file in the ISPROJ file.
    
  
  

Cons:

• There is not much documentation available about how to customize your ISPROJ file, which properties and items you must define to
  
  
  
  • choose the Release/Product Configuration you want to build,
    
  • override the merge module paths
    
  • override some MSI properties
    
  • override some path variables...
    
  You might need to analyze the InstallShield.targets file to find that out.
  

[DLee65]

Just to chime in here, for some reason my install of 2013 Premier does not include the InstallShield.targets file. It does include the MSBuild.xml file though that will provide a framework to use for your own MSBuild file. It is also interesting to note that this file imports the 'InstallShield.targets' file, that does not exist anywhere on a build machine or my development machine.

[rguggisberg]

Reureu wrote:

Cons:

• There is not much documentation available about how to customize your ISPROJ file, which properties and items you must define to
  
  
  
  • choose the Release/Product Configuration you want to build,
    
  • override the merge module paths
    
  • override some MSI properties
    
  • override some path variables...
    
  You might need to analyze the InstallShield.targets file to find that out.
  

Great info Superfreak3 and Reureu!
I need to do something like this. Currently I build 2 Releases (ServicesInstaller and WebAppInstaller) how do I specify that? This gets confusing because the MSBuild configuration apparently needs to be Debug or Release. So evidently MSBUild configuration and InstallShieldReleaseConfiguration are not the same thing???

[Superfreak3]

Our installation build machine instance of IS 2013 Premier does have the InstallShield.targets file in the defined location.

Thanks for the pros/cons information Reureu!

I definitely will delve deeper into this in the very near future.

Our current build script, after compiling binaries, runs a VBScript to make some adjustments to the .ism before building the packate (MaxVer field in Upgrade table, ProductVersion, an Add Remove Display version property we use to tweak what is seen in ARP - our version (#.#.#.#) not the .msi package ProductVersion (#.#.#), etc).

I'm thinking we might just be able to hack out the binary compiles and file staging from our current script and use the install build steps to accomplish deployment package compilation. I might try calling the script from the Build Definition as a first step if I run out of time playing with fully integrating IS into Visual Studio and the TFS build process as described above. I say this now with little knowledge, but exploration might change my mind.

[Superfreak3]

rguggisberg wrote:
Great info Superfreak3 and Reureu!
I need to do something like this. Currently I build 2 Releases (ServicesInstaller and WebAppInstaller) how do I specify that? This gets confusing because the MSBuild configuration apparently needs to be Debug or Release. So evidently MSBUild configuration and InstallShieldReleaseConfiguration are not the same thing???

Rguggisberg, I guess we could take this offline with PMs, but are you working with you installation template (.ism) as part of a VS project or scripting outside of TFS build? Not that this has any bearing on your question, I'm just wondering. If in a project, did you find it difficult to get everything up and running?

[rguggisberg]

Superfreak3,
Send me a test PM first to see if I get it. I had to change my password today because it was expired 😞 and I saw that they had my old email address. When I tried to change that I got an error that this email address was already in use (obviously that would be me too), so I don't know what email addy they are using. It was all part of a VS project when I started with it.

[Christopher_Pai]

InstallShield MSBuild support works great and has for many releases. The Visual Studio IDE integration has always crashed hard for me so I don't use it. What I do at my day job is we have a "Templates" directory in TFS with a small EXE that we run. It asks for project name and makes a copy of the template renaming and rebranding everything in the process. We then check that all into TFS and add it to our build definition | build process parameters | solutions to build list and it all just works. We never actually open the resulting .SLN in Visual Studio because it'll crash hard. Instead we just check out the .ISM and open it directly in the InstallShield IDE. Check it back in and get a CI build.

Recent versions of MSBuild supports something called Property Functions which is basically a way of calling .NET static methods and assigning the results to an MSBuild property. We find this a good way to gen a GUID that then gets passed to InstallShieldPropertyOverrides to support build that do Major Upgrades.

PS- Please note that InstallShield requires the MSBuild x86 platform. You'll get COM exceptions in your build results if you don't select this. It sure would be nice if they'd ever fix that. 🙂