/build/static/layout/Breadcrumb_cap_w.png

What are "releases" used for?

Hi!

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.

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. - Badger 9 years ago

Answers (2)

Answer Summary:
Posted by: deliveryboy 9 years ago
Orange Senior Belt
0

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.


Posted by: Badger 9 years ago
Red Belt
0

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.


Comments:
  • 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. - Agathorn 9 years ago
    • 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. - Badger 9 years ago
      • 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! - Agathorn 9 years ago

Don't be a Stranger!

Sign up today to participate, stay informed, earn points and establish a reputation for yourself!

Sign up! or login

Share

 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ