[wix-devs] Running WiX on Linux using Mono
anakin at pobox.com
Sun Jul 9 00:58:38 PDT 2017
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