Fixed as outline above (once I bottomed out the vbscript bug I'd introduced)

Scriptfille file now misbehaving.  Some days it just doesn't go your way... Faint, but pursuing

And the catalog path is initialized from catalog.xml....

I now remember why I hate this install game so much.

Prototyped everything and it just didn't work. The new catalog was never created, but the catalog.xml.in file was there.

After spending a lot of time I determined that vbscript change was working (you know how much fun it is debugging vbscript with printf with a 5 minute turnaround to rebuild the MSI). And it was fine.

It turns out that what happens is

• catalog.xml.in is created

• vbscript runs and catalog.xml is created

• Previous version unnstalled, deleting catalog.xml

I am having to cup of tea and will review my options

• Do the edit after RemovePreviousVersions. That's plenty late, and also it only works when the RemovePreviousVersions is at the end (which may not be true for every consumer of the merge modules).  If RemovePreviousVersions is before InstallFiles then the edit will also fail.

• Leave the phrases which install catalog.xml in place (to avoid the delete). but also add catalog.xml.in and use that to drive the (needless) substitution script. Longer term we can strip the substitution bit out, but the copy has to continue happening so as to stomp on the old version. This is probably the best plan since it keeps {{catalog.xml}} under component control (so it goes on final uninstall) but also fixes the update issue.

• I thought of an rejected out of hand any idea of changing the name or location of the catalog file. Lets keep this local and a result of history.

So I guess this bug always existed but we hadn't been updating the catalog files much if at all, just the schemas. Unfortunate.

The intent is that they be read only. Any user-supplied schemas would be in a separate file the user would create and add to the catalog path.