0

I have an installer that contains a uncompressed file:

<Component Id="Uncompressed">
    <File Id="UncompressedFile" Vital="yes" Source="Uncompressed.dll" Compressed="no" />
</Component>

This file can be replaced before actually installing the Package. That means, the version number at build time differs from the version number at install time. The MSI always contains the version at build time though. As a result the file does not get updated.

What possibilities do I have to:

  1. Check the file version at install time (ideal)
  2. ignore the file version for this file (if 1. is not possible)

Can I create the installer without actually supplying the file at build time?

In this related question there are some possible workarounds:

  • using REINSTALLMODE=amus
    => I would prefer a solution that only affects this single file.
  • Rename file on install (and undo on rollback)
    => Might work, seems hacky though
  • Companion File
    => Seems to be the best solution right now
  • Version lying
    => Won't work, since the File is a DLL that actually contains a version
  • This article seems to be exactly what I want
    => I'm just not sure how to use it.
Community
  • 1
  • 1
jacob1123
  • 361
  • 3
  • 12

1 Answers1

3

Your process is less than optimal. If the MSI's file table contains a version that is not the same as the file that you actually install, then there is potential for several issues. If the file version on disk never matches the version in the MSI then there is scope for repair issues, trying to correct the broken install. When there is a major upgrade (or a patch) Windows will see the versions mismatch and will not know if the file on disk should be replaced with the new one in the upgrade because it can't do a proper version comparison.

I would not attempt to perpetuate this situation. The easiest fix is to run msifiler.exe (from the Windows SDK) to fix the MSI File table versions when the file is replaced.

PhilDW
  • 20,260
  • 1
  • 18
  • 28
  • That makes sense. Unfortunately I can't use msifiler.exe since the replacement is done on client machines and the version number is not known beforehand. These issues don't seem to apply to companion files though. Are there other reasons to not use them? – jacob1123 Jan 26 '16 at 09:03
  • 1
    Yes, companion files is a good idea, and I assume you're thinking about having a versioned file with an incrementing version that controls the installation state of the randomly-versioned Dll. This is definitely worth a try. – PhilDW Jan 26 '16 at 19:03