Support cross-compiling releases to other operating systems

[caesay]

Right now, Velopack only supports bundling packages while running on the same OS that your package is targeting. This issue is just here to track current blockers which need to be solved before cross-compiling can work.

To build packages:

• On Windows, we use various Win32 API's, and depend on a variety of helper binaries that can't run elsewhere.
• On Linux, we need AppImage and FUSE support
• On macOS, we need a handful of native tools (productbuild, ditto, xcrun/notarytool, and so forth)

Building macOS packages on Anything Else - Because of the dependence on native mac tools, we will likely never be able to cross-compile to macOS.

Building Linux packages on Windows - It should be possible to run AppImage / FUSE on WSL, so we need to see how to detect that this is available and use it.

Building Linux packages on macOS - This is going to be difficult because it's not possible to run the AppImageTool on macOS, so we'd need to assemble an AppImage ourselves by downloading the corresponding runtime, creating a squashfs filesystem, and assembling the final package.

Building Windows packages on Anything Else - At the moment, we use a handful of native win32 api's, and native tools (zstd.exe, rcedit.exe, and so forth). Some of this functionality is cosmetic (such as changing an exe icon or resources). It may be possible to replace vital code with cross-platform equivalents, and just skip any non-vital/cosmetic functions. Of interest, I believe there is some cross-platform replacement for HostModel's ResourceManager going into .net9, so we may be able to benefit from that when it's ready. We could also include a build of https://github.com/mtrojnar/osslsigncode for signing

[dracossan]

+1. Will love to get at least the option to compile and sign my Windows//Linux binary on Linux. Using Gitlab internally for production pipe , with CD/CI on Linux, this will be really helpful. Having Mac OS will be even better, but seems long long way to go... thanks for these tools, save so much time and effort.

[caesay]

This is now supported in 0.0.523-g5727de1 - however not documented on the docsite yet. The basics are: you can change vpk mode by adding [os] to the beginning of the command. For example

• vpk -h will show help for current os (same as previous behavior)
• vpk pack will pack an app for current os (same as previous behavior)
• vpk [linux] -h will show you linux help
• vpk [linux] pack will pack a linux app
• vpk [osx] -h
• vpk [win] -h etc...

You can build linux and windows apps on any os (windows linux or mac). However, if you are building a macos package it can only be built on macos.

[AArnott]

Building a linux package from Windows:

dotnet vpk pack ... --mainExe Nerdbank.Zcash.App.Desktop --packDir bin/publish/Release/linux-x64 --runtime linux-x64

still fails with this error:

--mainExe does not have an .exe extension

This is true, but also not an error condition because the entrypoint for a linux executable usually doesn't end with .exe.

[caesay]

Working as expected; You must add the os directive as mentioned above (eg. vpk [linux] pack). The reason the directive exists (rather than it being picked up by the --runtime parameter) is because we need to know what OS you're packaging for before we do command line parsing. The requirements/validations and even the available arguments and help text differ by target operating system. The directives are something we can pick up ahead of time, before we parse args, such that vpk [linux] -h will show the available linux arguments, defaults, validations, etc.