5 replies to this topic

[eforinstall]

Hi,
I am using VS 2005 deployment project to build the MSI package. Our release convention is 1.01 formal release, 1.01.01 for beta release and 1.01.0101 for test release. So when I version the dll's based on the above convention, if I have 1.01.0101 installed and I am trying to upgrade this release with 1.01.02, the installer doesn't copy the versioned dll's. I ran the installer and generated installer log and I see the following messages for the dll's not copied.

Disallowing installation of component: {A682D5B1-62AC-229A-77FB-64A5B18F217B} since the same component with higher versioned keyfile exists

But if I install (1.02 over 1.01) or (1.01.02 over 1.01.01) or (1.01.0102 over 1.01.0101) it successfully deletes the older versioned dll and copies the new one.

Can someone help me understand what is going on? What can I do to force the copying of these dll's?

Thanks in advance for your help.

[Stefan Krueger]

That's because
0101 = 101
01 = 1
and 101 > 1

Each field of the version number is a number, and any leading zeros don't matter.

[eforinstall]

Hi Stefan,
Thanks for the reply. This is the versioning convention that we need to follow. Is there anyway I can trick the installer into copying the 1.01.02 version dll onto the 1.01.0101 dll?
Thanks.

[VBScab]

Unless you fancy re-writing the WI engine so that it handles additional version "sub-sets" (that is to say, where you would specify 1.01.01.01 instead of 1.01.0101) I don't think you have any choice but to use the RemoveFile table, if you wanted to just use native MSI functionality.

Beyond that, I think you're looking at Custom Action(s) to detect the actual file versions and branching accordingly.

There are more logical versioning systems that you could use but I imagine that changing yours would be beyond your remit and probably cast in stone anyway.

[eforinstall]

If we move to another deployment software like InstallShield or InstallAware, can I work around this issue that we see in Windows Installer?

[VBScab]

Both of those products default to producing MSIs. IIRC, InstallShield can create script-driven installs but I don't know what the versioning rules are. I wouldn't imagine them to be much different.

BTW, to be pedantic for a moment, these are packaging tools, not deployment tools. Deployment would be handled by, say, SCCM (neé SMS), Group Policy, Tivoli, Altiris Deployment System, etc.

Edited by VBScab, 22 December 2009 - 11:34.