https://bugs.winehq.org/show_bug.cgi?id=45208
--- Comment #25 from Zebediah Figura z.figura12@gmail.com --- I've been really trying to think of something to do with this, and coming up essentially empty.
Trying to emulate Windows behaviour here means not only adjusting the string table heuristics such that the string table is rebuilt during this custom action and this one alone—a difficult task if it's even possible—but also introducing an artificial slowdown to guarantee that our rebuilding process takes at least 5 seconds.
The installer runs a custom action which checks a global variable, calls GetTickCount() if it's unset, then repeatedly calls MsiViewModify(MSIMODIFY_INSERT_TEMPORARY), raising an exception when this fails due to primary key collision. Trying to introduce a hack to interrupt this sequence means, as far as I can tell:
* keeping old DLLs loaded in the custom action server. But this would reintroduce bug 10365. Maybe none of those applications are as widely used as Office 2010, but there are several of them, and I'd really like to not do this as it means trading one unsolvable problem for another.
* introducing slowdown somewhere in the normal sequence of operations. This would affect a huge amount of installers. The slowdown needs to be 5 whole seconds, which is patently absurd.
* adjusting MSIMODIFY_INSERT_TEMPORARY to not fail when collisions happen. This seems very dangerous, and liable to break other installers (if not this one). Besides which we'd be dropping entries in the table (and while many of them are duplicates, not all of them are).
The best thing I can think of to do is an application-specific hack. Despite that these have always been forbidden (except, for whatever reason, that one in winevulkan), I really can't see any better option. At any rate it's not a workaround for an undiagnosed problem; the problem is understood and all but unsolvable.
Otherwise I don't think there's anything to do but leave at least one bug in our tracker closed as WONTFIX.