2 replies to this topic

[Jamie]

Ok, I understand creating installs and updates for versioned files, however, I am still having some basic concept problems when it comes to unversioned files. Unfortunately, we have several applications made up mostly of unversioned files, so I think I had better get this one figured out.

Here's my scenario. I am using DevStudio 9 with Windows Installer 2.0. I have an application made up of several (actually thousands) of unversioned files in several folders. I am trying to figure out how to create components for all these files that will allow us to create upgrades and patches in the future. I tried to follow the component rules, but they don't have much bearing when it comes to unversioned files, so I have come to you for some answers.

From what I understand, only the KeyFiles will be looked at in an upgrade/patch situation. Since any number of my files may have their content changed in an upgrade, I looked into creating individual components for most of my files. Unfortunately that slows the build and install to a crawl, as the number of components gets way to large, so that's not really an option.

It was recommended to me that I create a component for each folder, which sounds more hopeful. If I am to do that, I notice that all unversioned files get an entry into the MSIFileHash table, which looks good but now I get confused. If I set one of the files as the KeyFile, and then in an upgrade situation, one of the other files has changed (a non-KeyFile) but the KeyFile remains unchanged. Will the upgrade recognize this file as changed because it is in the MSI FileHash table, or (as I have read) will it be completely ignored due to the fact that it is not a KeyFile? What about if I leave the KeyFile as undefined (use the directory). Will the file be recognized as changed in that situation?

As you can see, I really need some clarification on how Windows Installer works with unversioned files. Any assistance would be greatly appreciated as I have put off rewriting our installs for too long and need to get this started.

Thanks,
Jamie

[Jamie]

Ok, I've done some testing on this and am still a little confused.

I created a simple install with one component, which contains 6 unversioned files. I set one file as a key file and install. I then make a copy of the setup and change the content of one file (not the key file) and create a patch\update following all the required steps.

When I validate the upgrade, I get the validation error VAL0004:The file"xyz.xml" in component "Component1" is different from the file in the previous package, but the key file for this component did not change...
To fix this, Microsoft recommends creating a new component and move this changed file to that component and make it the key file. Simple enough.
However, if I don't do that but simply install the update over top, the output says:
MSI (s) (94:3C): File: C:\Program Files\My Company\xyz.xml; Overwrite; No patch; Existing file is unversioned and unmodified - hash doesn't match source file.
If I take a look, the file has been replaced properly.

So what I want to know is, if I encounter Val0004 errors, should I follow the Microsoft recommendation and create a new component each time, or can I simply rely on the MSIFileHash table to detect the change and replace the file?
Any insight at all would be greatly appreciated.

Jamie

[luke_s]

The way i used setup my unversioned files was by setting a companion file for each unversioned file. This meant that if the unversioned file was modified, it would not be updated, but if the file was not modififed, then it would follow the rule for the companion file. Bu now the MsiFileHas table can be used.

With your setup, I would probably just leave out the key file, and just let windows installer set the directory as the key file.
Following the Microsoft recommendation can get you into trouble if you are upgrading.
If you change the component guid, and do not change the component folder, and have RemoveExisitingProducts after InstallFinalize, then you can end up with an install that will remove the newly installed files because the old msi (RemoveExistingProducts runs a silent uninstall of the old upgraded msi file) will remove these files after they have been installed. Hope that makes sense!

I would read up a bit on the MsiFileHash table, and if that suits your needs, use this approach, and do not follow the Microsoft recommendation.

Make sure you create a few simple projects to test your upgrading, and patch scenarios before you move onto the larger project creation