Gareth Lennox

MSI version matching upgrade woes

We’re distributing our .net application using Microsoft’s MSI installer technology (using the very powerful WiX to do it).

We’ve recently seen a problem with the installer not upgrading older versions, but rather just installing on top of the existing version, which results in the application being listed twice in the “Add/remove programs” (Programs and Features in Vista) section, one for each version. This results in weird things happening, like uninstalling one of them leaves the other one still installed with all the application files removed.

I ensured that we kept the same upgrade guid, with the version number incrementing, but all looked good. After searching and trying different things, I finally found this gem, hidden away in the MS documentation:

Note that Windows Installer uses only the first three fields of the product version. If you include a fourth field in your product version, the installer ignores the fourth field.

Why?!??

Our version numbers are in the order of 3.2.0.1234, 3.2.0.1456 (where the 4th number increments based on the Subversion revision number). The installer was seeing the version numbers as 3.2.0, i.e. the same, and not uninstalling the old version. Changing the installer version number to 3.2.1234 fixes this.

WP Super Cache not caching (solution)

(this post is more a note to my future self than anything else)

The WP Super Cache plugin for WordPress is a pretty awesome plugin. The other day I was having problems with it not doing any caching and spitting out the following just before the head tag (where the wp_head() call is):

<!-- Page not cached by WP Super Cache. No closing HTML tag. Check your theme. -->

This was very odd. Everything I could find on the web regarding this problem was seeing this tag at the end of the html. Eventually I found a post that sounded similar to mine (and of course now I cannot find it again, unfortunately). It mentioned a plug-in using output buffering incorrectly. This makes sense, as looking in the source code of WP Super Cache, it outputs the message above in its output buffer handler if it cannot find a </html> closing tag. Needless to say, after a couple of hours fiddling, it turns out that it was a plug-in that I had written especially for the site, and it was doing exactly what the post mentioned (i.e. it was calling ob_end_flush() without calling ob_start()).

So it was all my fault, and I’ll probably do it in the future, hence this post!

So, note to self: If you see this in the future, check the plug-ins.