[wix-devs] Running WiX on Linux using Mono
rob at firegiant.com
Sun Jul 9 11:11:40 PDT 2017
1. FileVersionInfo - this is what I was concerned about with .NET Core. The .NET Standard says "vNext" of Mono will support .NET Core 2.0 (https://docs.microsoft.com/en-us/dotnet/standard/net-standard). If that is Mono 5 (just came out) or something reasonably soon, we may be okay. First step, reach out to .NET Core team and ask about that (https://twitter.com/robmen/status/884079880261910528).
As you note, worst case, we find a way to implement shim. Let's see what sort of answers we get from the .NET Core team.
4. "msi.dll" (from your follow up email) - Correct, we pinvoke to MSI. Does Mono do something special to redirect Pinvoke MSI.DLL to "libmsi.so"? ::MsiGetFileVersion() is one of those functions in "msi.dll" so perhaps we could solve the above FileVersionInfo issue with the same solution to solving ::MsiDatabaseImport()?
5. repo on wixtoolset - okay, let's pencil this in. It'll be a couple months (end of August, I expect) before we get to this point of adding specific Linux code. So, there is time to get answers to the above questions.
Finally, to be crystal clear, I'm not working on Linux (which is probably more than obvious at this point <smile/>). That means I'll be leaning pretty heavily on you (and Iain if he plans to stay involved) to run down things that get broken on Linux. I promise I won't purposefully be breaking things. It'll all be ignorance and a lot of it in the beginning. But, given the conversation here, I expect we'll get to a very solid working implementation.
From: Simon Tatham [mailto:anakin at pobox.com]
Sent: Sunday, July 9, 2017 12:59 AM
To: Rob Mensching <rob at firegiant.com>
Cc: wix-devs <wix-devs at lists.wixtoolset.org>
Subject: RE: [wix-devs] Running WiX on Linux using Mono
Rob Mensching <rob at firegiant.com> wrote:
> Any one know if FileVersionInfo is supported in .NET Core 2.0
> (wouldn't surprise me if it's something they left out)?
'Yes and no', apparently. A bit of poking around led me to
which suggests that the API exists in .NET Core, but its Windows
implementation works by delegating to the real Windows API, while the
Unix implementation source includes a comment mentioning that they
haven't so far seen a need to implement a PE resource parser, so it
looks as if it will just return stub values for the parts of the version
information that can't be acquired by any other means.
A quick test of my own, using a trivial 10-line C# program that
instantiates a FileVersionInfo and reads out the FileMajorPart /
FileMinorPart / FileBuildPart / FilePrivatePart fields (which I believe
are the right ones for this purpose), seems to confirm that. Compiled
and run with Mono, I get sensible version numbers out of my own PuTTY
executables, whereas running the same program under .NET Core I just get
So it _looks_ as if the answer is that if WiX switches over to using
FileVersionInfo, then it will compile all right under .NET Core, but
only the Mono runtime will run it correctly under Linux!
I'm now confused enough to be unsure if this is a show-stopping problem
or not. (Things were simpler when I thought we only had _one_ Linux
runtime to worry about...)
Assuming it's not a showstopper (or that we can find some other
approach, like having winterop.exe deliver file versions in an
emergency), I'll carry on and answer some more things:
> 3. winterop.exe - I would be willing to create and maintain a
> documented interface to winterop.exe (command-line input and stdout
> output) if you'd be willing to share the Linux implementation.
Certainly, if we get it working - I have no interest in keeping any of
this to myself.
> Additionally, I think the only code that will remain native is the
> dutil.lib based smart-cabbing work.
Really? Surely the whole family of functions that interface to
MsiOpenDatabase / MsiDatabaseImport / MsiDatabaseCommit and so on to
actually build MSI output files - i.e. the things I'm currently
implementing on Linux by calling out to GNOME msibuild - also have no
trivial x-plat implementation, so they would still need to live on the
winterop.exe side of the divide.
(In wix3 those live in a different native-code DLL from the cab routines
- msi.dll rather than winterop.dll itself - and I had to build shims for
> PS: "winterop.exe" may not be its final name but you know what I mean.
Of course - that's just a good enough name for us to both know what
we're talking about in this conversation :-)
> 5. "supporting project" - so let's explore options to execute on this.
> I'd be willing to give you a repo in the "wixtoolset" to place
> "winterop.exe" for Linux.
That's fine by me.
(I'd also have been happy to maintain my tool as a completely separate
downstream project in my own git repo collection, but this sounds nicer :-)
> 6. .cab extraction - WiX v4's intermediate representation doesn't use
> CAB files any more so this will not be an issue. Or rather, "Job's
> done". <smile/>
import hashlib; print (lambda p,q,g,y,r,s,m: m if (lambda w:(pow(g,int(hashlib.
sha1(m).hexdigest(),16)*w%q,p)*pow(y,r*w%q,p)%p)%q)(pow(s,q-2,q))==r else "!"
)(0xb80b5dacabab6145, 0xf70027d345023, 0x7643bc4018957897, 0x11c2e5d9951130c9,
0xa54d9cbe4e8ab, 0x746c50eaa1910, "Simon Tatham <anakin at pobox.com>")
More information about the wix-devs