Wrong build number exes after installation - PUZZLE!

[Sairen]

All right, crew, I've got a puzzler for ya.

One of my developers is seeing the following behavior. He'll grab the latest installer - say, it's build number 168 and it contains exes that are versioned 5.7.0.168.

After installation, in the directory that should have been full of 5.7.0.168, he has exes versioned 5.7.0.149. This has happened twice now, but just for one person.

I checked the built MSI, and it does contain exes of the correct version (168).

I checked his log file - this is a first time installation (always of some concern on developers' machines that THEY think it's a new install, but it's actually some freaky upgrade from something they forgot they installed or a downgrade or something) and there were no existing exes prior to the installation. The components containing the exes are marked for installation, and the FileCopy action indicates that there is no prior file, the exe will be installed, it is of the correct version, and being copied to the correct location.

In short, his log indicates that everything has worked absolutely perfectly. But when I go look at his directory in Windows Explorer... sure enough! Build 149! With the old date!

I even went so far as to ask that the installation had taken place on the same computer as the Explorer window -- just to be sure that he hadn't done one or the other in a VM and forgotten.

Can anyone guess what weirdness may be causing this?? Anything I should check?

Thanks!

[Richard_Winks]

I had a problem similar to this. It appears that if you have modified your ism project for thepackage and simply delete a component from the project then upgrades will execute with out complaint but nothing gets upgraded. It affects the entire upgrade content, not just the component that was deleted.

I found that in order to do what I wanted I had to revert to an old project, before the component removal, and then modify the component to remove all content. I started with a project that had the old component, I did not simply update the new project by adding back a component with the same name because a new component gets a new GUID.

This applied, in my case to a minor upgrade. I suspect that a major upgrade would work just fine as I understand that it uninstalls everything before installing the new components.

Hope this helps.
Richard

[Sairen]

Yep, I've seen that issue in minor upgrade as well. You can always look for the word SELMGR in logs, which indicates a change in components to look out for it.

However, that is not my issue here. This is a first time install, not a minor upgrade, and no file (not build 149) is present in the directory prior to installation.

Thanks for your input - hopefully it'll help someone else looking at this thread.

Anyone seen this on a first time installation?

[joshstechnij]

You may want to verify the file versions on a clean machine by running an admin install and checking the versions. If that appears to validate the correct file versions, the next step would be to use a tool other than Windows Explorer to view the file version properties. Explorer sometimes caches file information and does not update it correctly even when a file changes (though this is most common with icons for EXEs and shortcuts). A third party tool that always reads the version block directly from the file is a much more reliable method of checking the file version (a free tool, CFF Explorer, can be downloaded from www.ntcore.com; Visual Studio can also open an EXE file to view the version resources).