Jump to content

This is a ready-only archive of the InstallSite Forum. You cannot post any new content here. / Dies ist ein Archiv des InstallSite Forums. Hier können keine neuen Beiträge veröffentlicht werden.

Patching problems

4 replies to this topic


  • Members
  • 4 posts

Posted 18 May 2005 - 13:52

Because I am only recently getting acquainted with patching, this might be a beginners question (but you have got to start somewhere);

What's my problem:
Some time ago I created a .msi file for a custom made application for our company. Because this application is pretty new, we have to replace .exe's, .dll's,... on a frequent basis

In order to keep the workstations up to date with these updated files, we decided to create patch files that included these.

So, what I did:
- Copied the original MSI file
- Updated the files with the new ones (checked if the file versions where changed->ok)
- Updated ProductVersion 1.0.0 -> 1.0.1
- Compiled
- Ran UpgradeSync, and had the errors fixed (ran UpgradeSync, until no more errors listed)
- Created the Patch File (and generated log file)
- Log file clearly lists the differences between old and new .MSI

Then to test it, I first installed the old .MSI and afterwards patched it with the patch file (msiexec /p <path to .msp file> /qn REINSTALL=ALL REINSTALLMODE=omus)

In the Add/Remove Programs, I can find the entry that the patch has been installed, but when I check the files, it are still the old file versions (and the new files aren't added)

When I delete some of these files and do a repair, they are replaced by the new versions (so I guess it has patched the cached .MSI, but didn't apply anything to the installed files).

Can someone help me out, what can cause this problems?


Edited by tdumez, 18 May 2005 - 13:53.


  • Members
  • 121 posts

Posted 18 May 2005 - 15:50

What kind of keypath do the components containing the updated files have?

You should find that REINSTALLMODE=amus works, although it may not be the behaviour that you desire.


  • Members
  • 4 posts

Posted 18 May 2005 - 15:59

I'm not sure what you mean, but the files that need to be updated are in components that have these specific files as their file keypath

If I set REINSTALLMODE=omus then it should reinstall those files that have an older version installed.

a Reinstall all files (force reinstall – USE WITH CAUTION)
c Reinstall a file if the file is missing or its checksum is invalid
d Reinstall a file if the file is missing or if a different version is installed
e Reinstall a file if the file is missing or if the same or an older version is installed
m Rewrite all machine-specific registry entries
o Reinstall a file if the file is missing or if an older version is installed
p Reinstall a file only if the file is missing
s Reinstall shortcuts
u Rewrite all user-specific registry entries
v Reinstall from the specified source (MSI file) and re-write the local cached package


  • Members
  • 121 posts

Posted 18 May 2005 - 16:17

That was indeed my question.

Your logic appears to be correct although the results that you're observing don't tally.

Theoretically, using REINSTALLMODE=amus should replace the files too. I was simply suggesting that you could try this - not because this is the ideal solution, but because it might be interesting to check whether it does work as expected.

The best way to troubleshoot this problem is to switch logging on and analyse the resulting log file.


  • Members
  • 4 posts

Posted 19 May 2005 - 08:19

Attached you will find both the log file after applying the patch (patch.log), and the log file the Patch Creation toll generated(patchcreation.log).
Out of the patchcreation log file you can clearly see that it finds differences between the old and the new .dll , .exe,...files. But out of the patch log file, no action is done updating these files on the machine that has the initial MSI installed

Attached Files