[wix-devs] Running WiX on Linux using Mono

[Rob Mensching]

This isn't something we'll consider for WiX v3.x (WiX v3.x line is done) but there are big enough changes in WiX v4 that we can try to make life easier.

1. ::MsiGetFIleVersion() - I'm not thrilled about calculating file versions differently than MSI will when applying the install (given versions are so important) and I'm even less thrilled about parsing the file version information by hand. But if it can be shown that the C# FileVersionInfo class is a perfect replacement for ::MsiGetFileVersion() then I'd consider that like for like swap. I'm assuming that Mono (or whatever) has an implementation for FileVersionInfo.

2. ::MsiGetFileHash() - same as above but I'm more comfortable that MD5 is MD5 and we can get the DWORDs split into the table correctly, so I expect this one could just work out.

3. Cab compression in C# - I'm not at all interested at recreating "smart cabbing" in C#. However, I am very much thinking about getting rid of the multi-threading and winterop.dll and instead launching a process to do cab compression. Essentially, much of winterop.dll turns into one (or more) executable(s). If you've recreated winterop.dll already, not sure this helps significantly... but maybe.

4. Stopping at .idt files - unfortunately, with Merge Modules there are phases of processing that happen after .idt file generation (WiX actually uses .idt files to create the MSI today). You are probably avoiding use of Merge Modules today. So, I'll keep this request in mind but I don't remember the processing is as simple as you make it out to be here. <smile/>

5. .NET Core - I'm currently investigating how much of WiX can move to .NET Core. The goal isn't x-plat but if we get good solutions for the above and .NET Core makes the x-plat just work out, maybe this work moves from "we'll try not to completely break WiX use on Linux" to "get a 'winterop.exe' Linux binary from PuTTY" or maybe even "get 'winterop.exe' Linux binary from some side repo under github.com/wixtoolset)".


So how much of the above would actually help you? Are there are other tasks needed?


PS: Please keep the disparaging of Windows to a minimum. You are welcome to your opinion but voicing it in a project that primarily targets Windows isn't likely to accomplish anything but ruffle feathers of people who work on the project (aka: probably don't think Windows sucks).


Regards,

  Rob Mensching
  CEO
  FireGiant
_______________________________________________________________
 FireGiant  |  Dedicated support for the WiX toolset  |  http://www.firegiant.com/

-----Original Message-----
From: wix-devs [mailto:wix-devs-bounces at lists.wixtoolset.org] On Behalf Of Simon Tatham
Sent: Saturday, June 17, 2017 2:37 PM
To: wix-devs <wix-devs at lists.wixtoolset.org>
Subject: [wix-devs] Running WiX on Linux using Mono

Hello wix-devs,

I've been using WiX for a while to build Windows installers for free software I maintain (most importantly, PuTTY). Recently I've been making an effort to avoid having Windows involved in my Windows build process (mostly as a means of avoiding malware risks, although the extra speed is nice too). So I'm using clang for a C compiler; I've arranged a method of generating CHM help files without hhc.exe - and I've also found a way to run WiX under Mono, using assorted pieces of Linux free software to substitute for the tasks that WiX normally expects to delegate to Windows facilities like MSI.DLL.

My current system for running WiX under Mono involves a set of Linux shared library files that Mono loads in place of WiX's own 'winterop.dll' and friends. Using this setup, I'm able to use the unmodified candle.exe and light.exe from the standard WiX 3 distribution
- no need to recompile the CLR parts at all. If anyone's interested in looking at it in its current state, it's available here:

  https://git.tartarus.org/?p=simon/wix-on-linux.git;a=summary

But this system is not completely ideal, and I'd prefer to see if I can get some changes into WiX itself to make this easier. I've already raised this question in the bug tracker and posted some analysis there:

  https://github.com/wixtoolset/issues/issues/4381

and it was suggested that I should come here and ask for advice on the possible high-level approaches, before I do a really thorough writeup of a detailed plan.

What I'd personally like most would be if I could continue running the official distribution of the CLR parts of WiX, out of the box, without having to rebuild from source on Linux. So my first proposal would be to add some fallback code on the C# side, to be used if the native-code DLLs like winterop.dll can't be loaded. This fallback code would:

 - implement equivalent code to MsiGetFileVersion and MsiGetFileHash
   directly in C#, by digging through PE executables' resource sections
   for the former and MD5-hashing files for the latter.

 - implement CAB-building directly in C#, using Deflate compression,
   which I found to be easy enough given the published format
   documentation.

 - construct the actual MSI file by spawning GNOME 'msibuild', if it can
   find it on $PATH. msibuild expects a collection of .idt and .cab
   files as input, which is just what WiX has lying around anyway.

If people don't like the last one of those points (perhaps it's too Linux-specific, whereas it might be nicer to be even more platform- independent if we're going in this direction at all), another possibility might be to add a command-line option to light.exe which makes it write out a collection of .idt and .cab files and _terminate_ - leaving the end user to find their own way to put them together into an MSI. Then the Linux-based user would have to write a makefile flow that went candle -> light -> msibuild (not much more inconvenient than plain candle -> light), and users elsewhere would be able to come up with other plans if they could think of any.

A third possibility would be to essentially import my current solution directly into the WiX code base (with a lot of cleanup, of course!), without bothering to translate it out of C into C#, so that the WiX distribution would contain a libwinterop.so alongside its existing winterop.dll. I think that's probably less convenient for everyone (in particular, it adds a new OS requirement to WiX's own build arrangements, which my preferred solution avoids), but it is a possibility.

Of course, the last option is that none of this goes into wix at all and I carry on maintaining my current collection of Linux native-code libraries myself, and essentially function as a downstream of WiX for people wanting to use it on Mono. If there's no interest in taking any of these changes upstream, then that's what I'll have to do. (But in that situation I'll still hope to at least get in a bug fix or two upstream - e.g. there's an annoying issue involving the path-handling code not quite understanding Linux path syntax, which I currently have to work around in an ugly way with LD_PRELOAD.)

What do people think? Would any changes along these lines be welcome at all? If so, which of these options sounds good? Have I missed any possibilities?

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> ____________________________________________________________________
WiX Toolset Developer Mailing List provided by FireGiant http://www.firegiant.com/