[wix-devs] Running WiX on Linux using Mono

[Simon Tatham]

Blair Murri <osito at live.com> wrote:
> My vote would be along the lines of moving things into C#. What I
> don't favor is a having potentially platform independent code unused
> in the majority platform (i.e. don't write (much) code in C# that
> won't be run on Windows).
[...]
> Not sure how to balance those two requirements, although a .idt/.cab
> output from light isn't necessarily a bad idea from my POV.

Mmmm. That does make a lot of sense - stopping at .idt/.cab output adds
the minimum code to WiX itself, and keeps all the Linux-specific details
in some Linux downstream wrapper script which from WiX's point of view
is Somebody Else's Problem (and which would still look much nicer than
my current one :-).

Supposing for the moment that we do head in that direction, that still
leaves the problem of the Windows native-code functions that WiX needs
to call _before_ it gets to the stage of outputting .idt and .cab files.

One of those is .cab construction itself, of course, which happens _only
just_ before that stage. So perhaps instead of 'generate .idt and .cab
files', a better stopping point might be 'generate .idt files and a
description of what .cabs to construct containing what files under what
names'? Then even the .cab construction could be offloaded to the SEP
wrapper script.

The other, as I mentioned on the bug tracker, is the part where WiX
calls MsiGetFileVersion to retrieve the built-in version number from PE
executables, and for files that don't have one, calls MsiGetFileHash to
compute (what turns out to be) the MD5 hash of the file. The results of
those calls end up in one of the the .idt files, and if WiX can't get
them from msi.dll then it has to get them from somewhere else.

In the same spirit of 'outsource to the user anything you can't do in
the standard Windows way', perhaps a solution to this part would be to
provide an auxiliary input file to light.exe which provided the version
and hash information for all relevant files? Or conceivably a syntax
extension to the .wxs input format itself (e.g. an extra attribute in
the <File> element), though I think that's probably less convenient all
round.

Cheers,
Simon

-- 
for k in [pow(x,37,0x1a1298d262b49c895d47f) for x in [0x50deb914257022de7fff,
0x213558f2215127d5a2d1, 0x90c99e86d08b91218630, 0x109f3d0cfbf640c0beee7,
0xc83e01379a5fbec5fdd1, 0x19d3d70a8d567e388600e, 0x534e2f6e8a4a33155123]]:
 print "".join([chr(32+3*((k>>x)&1))for x in range(79)]) # <anakin at pobox.com>