What is the purpose of product configurations and releases in InstallShield? Usually I just go to "Project Assistant" and build a MSI-file from there.
Is there a way to save different build configurations to test different "versions" of a project before final build time? I have experimented with it but it doesn´t seem to be what releases is used for.

Sorry for the, perhaps, stupid question but I´m unable to find a clear answer for this.
Answer Summary:
1 Comment   [ + ] Show Comment


  • that would kind of put you in the sourcesafe (other products are available) sort of place. it takes care of handling the ISM. if you rename the ISM, remember when you build the MSI it creates the top folder level with the ISM name. I understand its nice to roll back, but you just need to be careful with your edits. If you change 100 reg keys, then remove 20 new components, that is big change stuff.
Please log in to comment



If you work in an IT packaging function you are less likely to use this as it is typical to create a single release.

If you were a setup author for a software vendor it is more common to have multiple release/configurations to suit specific customer and or regional requirements. In addition you might want to bundle a setup.exe launcher with your release as well as just an msi and make both available via your download site for example.

Hope that helps.

Answered 03/12/2015 by: deliveryboy
Orange Senior Belt

Please log in to comment

The prod Config and releases in Installshield are what answers your 2nd question. It is very much a developmental method of working, keep building new releases, InstallShield does that for you. It saves you have to copy the MSI, rename etc

I would recommend always starting with an ISM, a project file, then when you play with that, InstallShield automatically adds a new build for you. If you are making loads of changes and keep 'building' you can press f7, this will rebuild the current config and release (overwrite) . It can be useful instead of having dozens of builds.

You can also create upgrades from the ISM (you cant do this in the MSI with InstallShield using the GUI, only tables),  handy if you create an MSI then a year or so later you have to modify (upgrade) it.

Answered 03/16/2015 by: Badger
Red Belt

  • Thanks for the reply! However I dont quite understand how the releases and build versions work. Is it possible for me to, for example, complete a release 1 and build an MSI. Test the package and find out that something it wrong. Then make a change and make a release 2 and build an MSI from that? Can I later go back to release 1 if release 2 didn´t work somehow? When I tried it the changes arent saved in the project, it just overwrites the old values (for example I created a public property named "RELEASE1=1" in release 1 and "RELEASE2=1" in release 2 and when I try to "go back" to release 1 the property is still "RELEASE2=1". Apparently I´m doing it wrong. Or perhaps this isn´t the way it´s supposed to work? I´d like a way to experiment with the ISM-projects and still have a way to "go back" instead of having to document every changes and manually change them back again if things doesnt work out.
    • just incase you are missing a point, use an ISM file, don't build an MSI directly. To your question....
      Yes it is possible, that is exactly what it is for. Do NOT put the release properties in the MSI.
      build Prod Conf1, rel 1, test, change, then build rel 2, rel 3 etc.
      since it build the MSI in a completely different folder structure, the older release is preserved.
      But bear in mind, if you modify the ISM, build a new release, you can keep the older MSI, but the changes will be saved in the ISM, with out something like sourcesafe, you have to figure out manually copying the ISM.
      If you choose the build wizard you can build a new release, or overwrite an old release.
      you can also go into the Media section of the ISM (NOT the table) and see all the prod configs and releases and build what you want.
      how much changes are you making in the ISM??
      if you set the proj type to be XML instead of Binary you can compare differences between ISMs, but you still have to keep copies.
      • Oh ok I think I understand now. And yes, I´m talking about ISM:s and not editing MSI:s with MST:s.
        I wanted to have a way to track changes in editing my ISM:s and a way to easily go back and forth in ISM-changes. But this is simply just a way to compile different MSI:n without having to copy the MSI before compiling again?
        Usually I make the changes I want to the ISM and compile and everything works as intended. But sometimes when troubleshooting I try out different solutions and then I save the ISM:s with different names etc so I have a history. It would be nice to be able to have all these changes in the one ISM-project. Thanks for your reply!
Please log in to comment
Answer this question or Comment on this question for clarity