Error importing idt during WiX unit test compilation. Possibly due to bits set in top word of column value

[bevanweiss]

Hi,
Just wondering if this is a known issue with Windows installer stuff...

I've added a new column to the Wix4IIsWebDirProperties table for DirBrowseFlags, which is 32 bits of possible flags.
i've tried it both as an .Integer and as a .DoubleInteger column category, and with length = 2 or 4.
Anytime I try to set a bit in the high word, I get this error.

[xUnit.net 00:00:07.93] WixToolset.Core.Native.Msi.WixInvalidIdtException : There was an error importing the file '...\AppData\Local\Temp.WIXTEST ytr5ix0v.b1a_idts\Wix4IIsWebDirProperties.idt'.

Is there a standard way of handling this (i.e. do I need to split it into two columns of <=16 bits each or something)?

[barnson]

Maybe #8056?

[robmen]

Does it have to be a new column? Can the existing attributes column be used, just with different enum values?

[barnson]

That evokes the using-merge-modules-from-WiX-v3 problem that led to the Wix4 table prefix.

[bevanweiss]

Does it have to be a new column? Can the existing attributes column be used, just with different enum values?

It's the WebDirProperties table that would need the extra data, and unfortunately no generic 'attributes' column exists...
https://github.com/wixtoolset/wix/blob/7288b0b76f8b902510631fa70ae2b8b962dbf589/src/ext/Iis/wixext/IisTableDefinitions.cs#L101-L120

I'm not too familiar with merge-module logic. Adding new columns just isn't supported at all, or does it result in a mix of rows with nulls vs non-nulls, or a new CA that is potentially executed against an old table schema (i.e. the table query would fail because that column doesn't exist)... I'll have a read up on the Windows Installer merge module doco (happy for other references if available).

[bevanweiss]

That evokes the using-merge-modules-from-WiX-v3 problem that led to the Wix4 table prefix.

My check through of Windows Installer Merge Module doco seems to imply that a Merge Module can't change the schema of an existing MSI table. Is that indeed the case?
It would certainly make things a bit trickier.

Perhaps it might be a good time to start to introduce 'version' type of information into Wix installers. i.e. perhaps a WixVersions table which has a record for each of the shipped Extensions that was used within the component (i.e. IIs / Firewall / Util etc etc).
At least in this manner in the future having custom actions handle different versions of the source data might be possible.

Ideally something like EF 'migrations' might be possible, so if a V7 merge module is applied to a V4 MSI then the V7 Custom Action DLL and V7 schema are the result of the merge somehow.. likewise if a V4 merge module is applied to a V7 MSI then the V7 Custom Action DLL and V7 schema should result still..
I imagine the details would not be as simple as I hypothesis however...

[barnson]

If the table schemas change, we rename the table to avoid conflicts when someone uses a merge module built with a previous version of WiX.