7 replies to this topic

[Seany]

Hello

My company produces support releases with 4 digits in the version number.

e.g. 1.2.3.4

Am i correct in thinking that installshield will only recognise the first three digits?

If I create a version 1.0.0 and a version 1.0.1 then when installing version 1.0.1 over version 1.0.0 it installs as an update. i.e. the install runs in the update mode and installs over the top of version 1.0.0.

However if i create version 1.0.0.1 then when i install it over 1.0.0 I get the repair/remove/modify screen. (Installshield still thinks its just version 1.0.0)

If I select Repair it still seems to do what I want, i.e. installs newer versions of files and new files etc. but is there any way of getting Installshield to recognise the 4th digit change and run in the update mode rather than having to select Repair?

Thanks for your time

[MSIYER]

Am i correct in thinking that installshield will only recognise the first three digits?
Yes you are absolutely right. Anything that Installshield does is in accordance with the Windows Installer rules. So, Windows Installer does not recognize 1.2.3.4
scheme. It understands the major.minor.build scheme only. Fourth parameter is ignored.

If I create a version 1.0.0 and a version 1.0.1 then when installing version 1.0.1 over version 1.0.0 it installs as an update. i.e. the install runs in the update mode and installs over the top of version 1.0.0.
Yes. It purely depends on what type of update you configure for your user. Patch or Full Install etc.

However if i create version 1.0.0.1 then when i install it over 1.0.0 I get the repair/remove/modify screen. (Installshield still thinks its just version 1.0.0)
Not necessarily. Let me explain:
When you modify your product by making changes to some binary/ies and provided the changes are so trivial that, even manually replacing the binariy/ies on end-user machines would update the installation, you have effectively created a small update.
Any change in the components is a change, nevertheless. That means, you need to change the Package GUID. This gives you a new package. So, you cannot run it on end-user machine an expect a Repair.

Now what happens if you try to trick the Windows Installer Engine by not changing the Package GUID and keeping your version as 1.0.0.1?
This will be seen by the Windows Installer Engine as the same old package and Repair will be triggerred. WOW.
But NO. That will NOT happen.

This is where msi caching comes in. When you installed version 1.0.0.0, the Windows Installer Engine cached a copy of the msi database on the system in a hidden directory. It also noted down:
The package GUID,
The version number,
The source directory,
in addition to the millions of other things that it stores in various places but primarily the registry.

When you trigger a 1.0.0.1 setup with the Package GUID = 1.0.0.0 Package GUID,
you will surely find Repair happening. But the msi used will be the cached one. The Repair, this time, as always, will simply re-install the version 1.0.0.0 files.
Your updated binaries will not reach the end-user machine.

Hope this helps.

Edited by MSIYER, 08 June 2011 - 13:11.

[Seany]

Hi

Thanks for very speedy and detailed reply.

My install is currently installscript based so I don't think I'm using the msi at all?

I think if I change the GUID of my installscript project the new verison will be seen as a seperate project and will install along side the already installed version?

So i would end up with both version 1.0.0.0 and 1.0.0.1 on the same machine?

[MSIYER]

My install is currently installscript based so I don't think I'm using the msi at all?
Well the installation of my brain needs some repair now. I posted about Basic MSI properties when the section is for Installscript projects.

I think if I change the GUID of my installscript project the new verison will be seen as a seperate project and will install along side the already installed version?
Yes that should be the behaviour. Installshield engine relies on the Product GUID and version number to check for already installed apps and for upgradation.
So in your case, I believe, you will have two products installed side by side :
version 1.0.0 of Base Product
version 1.0.0 of updated Product

version 1.0.0.1 of updated product will be seen as 1.0.0 only.

If there are workarounds they would be quite complex to achieve.

I assume that you are using Standard repair and Maintenance options. A copy of the full setup is stored in a hidden directory named "{RootDrive}\Program Files\InstallShield Installation Information" during installation. This is invoked during repair.

Well the only major difference between the original setup folder and the one cached in the hidden folder is the setup.ini file. Compare them and you will understand. Many things can be achieved by manipulating the setup.ini.

Try experimenting with modifications to your version 1.0.0.1 setup.ini and see how it works. Making the version 1.0.0.1 setup look like your cached version 1.0.0.0 setup is what I mean.

hope this helps.

Edited by MSIYER, 11 June 2011 - 10:11.

[Seany]

Hi
Thanks again for super speedy response.

I think what I've decided to do (and will be acceptable by the powers above me) is to use my third digit as two digits.

e.g.
version 1.0.0.1 will be 1.0.001,
version 1.0.1.0 will be 1.0.100
version 1.0.1.1 will be 1.0.101 etc.

I think this will work?

[Taco Bell]

This section is dedicated to pure InstallScript projects MSIYER that don't use Windows Installer, so a lot of things you're bringing up here don't apply in Seany's case.

[MSIYER]

Thanks Taco Bell.
My first post was inappropriate in this section. It was for Basic MSI.

I understood my folly when Seany pointed out.Thus, I posted again about Installscript projects.

The second post of mine concerns with Installscript projects and how product version number rules apply to it.

So I feel everything is sorted out.

Edited by MSIYER, 11 June 2011 - 11:17.

[Taco Bell]

Understand MSIYER and sounds good.