Update Avalonia to latest version, enable basic PublishAot scenario

[filipnavara]

Unlike #645 this takes a very minimalistic approach to the Avalonia upgrade. It updates all code to compile and run but it doesn't add Browser support or any optimizations.

For the AOT part, .NET 8 TFM build is added to StructuredLogger with couple of annotations. Additionally, the TinyJSON parser is replaced with source generated System.Text.Json deserializer. I didn't update this for the netstandard2.0 build since I don't want to add dependency on out-of-the-box package.

[filipnavara]

I am not sure what is this supposed to bind to. It's necessary to provide a proper context for the compiled bindings.

[filipnavara]

For reference, on macOS ARM64 this produces 30Mb self-contained executable and about 20Mb of native libraries:

-rw-r--r--  1 filipnavara  staff       758 Jan 31 13:48 Info.plist
-rwxr-xr-x  1 filipnavara  staff  31278800 May 26 23:51 StructuredLogViewer.Avalonia
drwxr-xr-x  3 filipnavara  staff        96 May 26 23:52 StructuredLogViewer.Avalonia.dsym
-rw-r--r--  1 filipnavara  staff     30924 May 26 23:45 StructuredLogViewer.Core.pdb
-rw-r--r--  1 filipnavara  staff      1702 Jan 31 13:48 StructuredLogViewer.icns
-rw-r--r--  1 filipnavara  staff    174512 May 26 23:51 StructuredLogger.pdb
-rwxr--r--  1 filipnavara  staff   1341120 Apr 25 09:03 libAvaloniaNative.dylib
-rwxr--r--  1 filipnavara  staff   2683424 Apr  9 18:58 libHarfBuzzSharp.dylib
-rwxr--r--  1 filipnavara  staff  15084640 Apr  9 18:58 libSkiaSharp.dylib

[slang25]

@filipnavara this looks great. Now that Avalonia 11.1 is out, are you intending to come back to this?

[filipnavara]

Sure, I can update it to 11.1.

[slang25]

Interesting, the arrows seem to be working here after I pulled it down and tried it (both AOT and non-AOT).

[filipnavara]

I pushed a commit that fixed the arrows. 😉

[slang25]

I've been using this locally and it all seems good from my perspective 🙂

[slang25]

@KirillOsenkov would you be able to review when you get a chance, we can then follow up with some macOS packaging improvements following this guide

[KirillOsenkov]

Yes, I'll try to find time within the next couple of weeks, sorry I'm super busy as always.

Do you think theoretically this PR is ready to go or does it need more work?

Should we perhaps look at #645 as well and see what can be salvaged from it? I don't know what the state of these two PRs is.

[filipnavara]

Do you think theoretically this PR is ready to go or does it need more work?

It is ready to go. The non-browser bits from #645 are salvaged here.

[KirillOsenkov]

Thanks! I really appreciate the help!

[KirillOsenkov]

Since this is now merged, could someone with a Mac try out the latest main, try out the instructions to build the Mac version, and see if it all works fine?

Also our AppVeyor build is producing two zip files with Mac versions for x64 and arm64, do these need updated? Should we start publishing the AOT versions? Sorry I'm not a Mac expert and not sure what's best here.

Every time I publish a release I've been also publishing these two Mac zips in each release.

[filipnavara]

Since this is now merged, could someone with a Mac try out the latest main, try out the instructions to build the Mac version, and see if it all works fine?

It should. I've been primarily testing it on macOS.

Also our AppVeyor build is producing two zip files with Mac versions for x64 and arm64, do these need updated? Should we start publishing the AOT versions? Sorry I'm not a Mac expert and not sure what's best here.

Ideally we should publish a single universal app. That's a bit tricky with Avalonia. Under normal circumstances you just target net8.0-macos TFM and specify RuntimeIdentifiers=osx-arm64,osx-x64 and the MSBuild magic in Microsoft.macOS SDK does the job for you.

However, historically Avalonia doesn't depend on the macOS API bindings from net8.0-macos TFM and uses the universal net8.0 TFM only. That means you either have to use 3rd-party NuGets to do the bundling job, or follow the official tutorial.

Either way, to do proper macOS publishing one needs an Apple Developer account and appropriate certificates. Otherwise you cannot sign the app, and distributing unsigned / ad-hoc signed (ie. signed but without dev certificate) is quite pointless. Such apps cannot be run on modern macOS without resigning or system-wide integrity turned off. Neither of those options are practical.

I do have templates to setup the Apple distribution with a valid developer account, but it still means going through the legalese of creating the account and paying 99 USD per year which may be hard pill to swallow. The alternative is offering source-only builds, or global .NET tool (which is ad-hoc signed on the target machine on installation).

[filipnavara]

Small correction to the post above. There are apparently still free Apple Developer accounts. I was not sure if that was still the case, but it's still advertised on their web.

[slang25]

I can confirm the latest AppVeyor zip worked for me with the instructions in the README

[slang25]

The free apple developer account thing seems to be a sort of trial, rather than a free offering for open source projects.

I'd be happy to cover the 99 USD per year, through GH sponsorship of whatever is most appropriate.

[KirillOsenkov]

ok let me do some research on the apple dev account...