8 replies to this topic

[pk78scout]

Hi,

I'm having a hard time with file versions. Here's what I'm doing. First, most of the files in our application are NOT binary and therefore we seem to have absolutely no way of assigning file versions to them. Many files are .txt, .mdb, and other files written in Prolog which don't have a version tab if you right-click file in windows explorer and look under Properties. If there was a way to assign versions to non-exe as well as non-dlls maybe my problem would be solved.

So I use "override system version", and it lets me replace files when I'm upgrading. But I have files in a merge module, and this merge module is shared by multiple applications. Now, over time, the each application is distributed/built with different versions of the merge module. So if product A is older than product B, but product A is installed after product B, then product A (with older files) overwrites newer files that were installed first by product B! This happens even though I assigned what some call "fake" file versions in InstallShield.

Now I'm beginning to think that the file versions as I've used them are only used during an install. But once a non-exe or non-dll file is installed, since it doesn't have a "permanent" file version then with future installs the installer doesn't have any way of truly comparing file versions!!

I was originally hoping that somehow those "fake" file versions that I assigned would be remembered in the msi table so that even when other apps shared files (merge modules), the windows installer would "remember" the orignal (fake) file versions that I assigned.

It would be GREAT if I could find a way to permanently assign file versions to plain old regular files like .txt, .mdb, and other miscellaneous resources.

Idea: if I change product version of merge module, even if I only update single file, would that prevent "downgrading" when older products with same (earlier) version of merge module are installed after newer versions?

Many thanks.

pete

[Stefan Krueger]

These fake version numbers are indeeed only used during installation. They are not assigned to the installed files. That's why this method is called "version lying".

What you could do is use Companion Files, i.e. base the overwrite decision on the version comparison for some other file. This might be your main executable, or maybe some dummy file that you only install for this purpose (an empty DLL that only carries version information).

Another approach would be to tell the setup not to overwrite existing files. In a custom action that executes before the file copy, you would do "something" to decide whther these files need to be updated (e.g. look for version information in a registry entry). If you find they need to be updated your custom action would delete those old files. Now they are gone your setup will install the new files.

[pk78scout]

I was afraid of that. But thanks so much for your reply.

I tried modifying merge module version as a way of preventing downgrade but it didnt' work. That is, I installed product B with newer merge module version, and then tried installing product A which was built with previous (lower) merge module version and windows installer acted as though there were no difference in the merge module versions. It went ahead and installed older files over newer ones.

I thought that windows installer would prevent older product versions from replacing new ones - isn't that one of the ways authors can control order of installs and upgrades?

Thanks again for your help.

-pete

[Stefan Krueger]

Windows Installer prevents older file versions from overwriting newer files.
With some additonal settings you can make sure that it won't overwrite a newer product (comparing ProductVersion) as well.
The Merge Module version however is only used during the merge process (at build time, not at install time).

[pk78scout]

Okay. I went with "companion files", making up dummy DLLs as the key files. But now when I try to create a patch I get VAL0004 errors on 2 files in my merge module, which I have never had on previous patches. I know what the error means, but I think it is suspect. It says my ".mdb" file changed but my key file did not. Neither changed, actually. So I don't know what else to try. I wonder if something is getting changed behind the scenes that I don't know about. Here's what I mean:

When I define the key for my companion ".mdb" file, I enter "my mdb component name.componentGUID" under "override system version". I wonder if the component GUID is somehow getting (temorarily?) changed by windows installer/IS during/after build time? It doesn't appear to be when I look at it in the IS viewer.

My patch has nothing to do with merge module changes. In the patch I'm adding a brand new component to existing feature of the main setup (using MSI 3.0).

I don't know what to fix because neither the key file nor the companion file in the merge module have changed.

Thanks very much,
pete

[Stefan Krueger]

The mdb file is exactly the same? Please do a binary comapre to be absolutely sure. Also the file date and time should be exactly identical.

[pk78scout]

Thanks for the reply. I haven't done binary compare yet. Many years ago I knew how to do this in UNIX but I don't know how in Windows. However, I have checked dates and file size as shown in windows explorer and nothing has changed. The "mdb" file has a February date!

Here's how I do the patch build: I build uncompressed "base setup" and save it in separate location for use as "previous setup". Then I add new component to existing feature, then rebuild uncompressed base setup. For patch I point to each of these versions to create the patch. There are no changes to the files in the merge module. The merge module is just another part of the base setup but it is NOT changing. In fact, the first build and the second build take place only about 7-10 minutes apart. I don't see how the merge module files could be changing. That's why I don't trust what Installshield is reporting. I'm not saying they haven't somehow been changed internally by some process I'm not aware of, but I just don't know why that would be.

Is it possible that a change made a while ago is still being remembered or cached by either IShield or windows installer? If so, is there some setting or procedure to rebuild from scratch or flush the cache?

As you can see, I'm purely guessing now. I thought I heard of prior errors/bugs in installshield that incorrectly produced val0004 errors in the past.

If I clear the keyfile attribute (i.e. no key file for problem component), would that take care of the problem? If so, then I'm okay with consequences of having windows installer check each file in component instead of just checking install state of only the key file.

Thanks again,
pete

[Stefan Krueger]

For a binary compare either use WinDiff from the Platform SDK, or from the DOS command line:
fc -B file1 file2
(fc = file compare, -b= binary mode)

If you don't specify a key file for a component, the folder itself becomes key, i.e. no files will be compared. That's not what you want.

[pk78scout]

The fc command worked just fine. Thanks. Unfortunately, there is NO difference between either the key file or the companion mdb file. Of course, I knew that, but now I know for sure.

So that has got to be some kind of bug. I don't know what else to try.

If you specify no key file, the folder becomes the path and no files are compared? I guess you mean that the folder path becomes the "key path" and no files are compared "at a high level", and the windows installer is forced to check each and every file in the component, using versioning rules and all the other "file replacement" rules on each file? That must be, because I don't have "key" files in all of my components and files are still getting replaced properly. Or am I missing something there, too?

I'm stumped with the val0004 problem. Not sure what else to do. If I drop the key file, I don't get the val0004 error and I can apply the patch successfully. My next test will be to update companion file in merge module without "key file" being designated.

Thanks,
pete