Cross-platform package building and deployment

[caesay]

Now that Squirrel is on dotnet 6, there is no reason we can't build cross-platform binaries and consider adding support for other operating systems.

Windows arm64

There are not a lot of code changes required to support arm64 properly, most of this is just recompiling binaries. There also should not be any compatibility issues creating x64 packages on arm, or vice versa.

To support applications being deployed to arm64:

• Add appropriate enumerations to RuntimeCpu
• Update AssemblyRuntimeInfo to check for ARM when detecting OS machine architecture
• [ ] Compile StubExecutable.exe, Setup.exe, Update.exe for arm64. (they are all x86 at the moment, technically windows on arm supports x86 emulation, so maybe we could skip this) (x86 binaries can be virtualised on x64 and arm64)
• Update SquirrelCli.Releasify to check for incompatibilities between x86/x64 and ARM when building packages and store the correct machine architecture into the package metadata.
• [ ] Also update SquirrelCli.Releasify to use the appropriate Setup86 or SetupArm64 (and Update86/etc...) depending on the package architecture. (not needed since we are only building x86)
• Update error message logic in Update.Setup when checking current architecture

To support compiling releases on arm64:

• Update WiX and investigate how to build an arm64 MSI (WiX + ARM64 wixtoolset/issues#5558 (comment))
• [ ] Compile Squirrel.exe for arm64 (not needed as Squirrel.exe is now a cross-platform csq tool)
• Add arm64 variants of other vendor binaries or confirm that they can run successfully on arm64 (rcedit, signtool, singlefilehost)

macOS

I do not believe we can support building packages for macOS on windows as codesign and xcrun/altool is not available. Similar issues trying to build windows packages from MacOS, but we can use Wine to fill in some of the gaps. I will not support installing dotnet runtimes on linux/macos, so only self-contained apps will be supported.

We can create universal binaries for mac that work natively for more than one operating system / cpu architecture using lipo, this seems to be preferred instead of having separate downloads in Apple's ecosystem. Example:

clang++ main-mac.mm -o bin/mac_x86 -fobjc-arc -framework Cocoa -target x86_64-apple-macos10.12
clang++ main-mac.mm -o bin/mac_arm64 -fobjc-arc -framework Cocoa -target arm64-apple-macos11
lipo -create -output bin/mac_universal bin/mac_x86 bin/mac_arm64

We should probably bundle RID osx.10.12-x64 and osx.11.0-arm64 at a minimum to cover off the two widely used CPU architectures.

We install to %localappdata% on windows, the closest thing on macos is probably %userprofile%/Applications which seems to be uncommon but used by some.

• Generate .app bundle during releasify instead of Setup.exe
  Can look at https://docs.avaloniaui.net/docs/distribution-publishing/macos for some inspiration.
• Binaries need to be codesigned, and .app bundle needs to be notarized.
• Create a .pkg which installs the application into ~/Applications (NOT /Applications)
• Use a 'current' directory instead of 'app-{version}' for the latest app version #24 needs to be completed
• Comb through Utility, make sure all the file paths, process starts, process enumeration etc have abstractions for macos
• Cross-platform ZIP implementation to replace 7z
• Remove MsDelta logic, we have bsdiff anyway and it's faster
• Review temporary paths used by UpdateManager, these can not be stored in the app folder like we do on Windows.
• Replace the "Apply Updates" logic, remove shortcuts, registry entries etc. We'll update the program by just replacing the current .app with a new one.
• Create a new Update.exe for macos - most of the windows functionality is not relevant, we really only need it to swap out the .app bundles during an update.

[caesay]

MacOS support is released in 3.0.143

[caesay]

Closing this issue for now as the points for both windows and mac are resolved:

• mac support is here,
• the package builder is now a cross platform dotnet tool
• windows 11 arm64 now supports x64 emulation

Will open a new issue if/when I end up looking at linux support.