Added Uno Platform support

[xperiandri]

#186

[xperiandri]

@neuecc approve the workflow, please

[neuecc]

This would make R3.WinUI3 exclusive to Uno, which is unacceptable.

[xperiandri]

What do you mean by exclusive to Uno?

[xperiandri]

@neuecc
You can see here that it adds net8.0;net8.0-windows10.x.xxxxx
This means that the NuGet package will have code for WinUI and for all Uno-supported platforms

[neuecc]

Thank you, I understand.
I was mistaken.
However, I'm not very happy about changing the Project Sdk to Uno.Sdk or having complex conditions.

Also, I'm not very familiar with Uno, but is it okay to have only WinUI3 support it?

[xperiandri]

Also, I'm not very familiar with Uno, but is it okay to have only WinUI3 support it?

No, because it makes almost no sense to build WinUI apps without targeting the other platforms that Uno provides.
Who will build a single desktop app in 2024 🙂

[xperiandri]

All the project setup I used I copied from Uno project template

[xperiandri]

Nothing from myself 🙂

[xperiandri]

Uno.Sdk just simplifies the csproj logic

[neuecc]

This PR for Uno support seems to function only in WinUI3.
For example, the Avalonia support covers all of Avalonia.
I would like a detailed and thorough explanation; otherwise, I will have to close this PR.

[xperiandri]

Uno provides source compatibility on the Android, iOS, MacCatalyst, GTK (Linux/WPF), and WebAssembly platforms.
Technically it converts XAML into C# code manipulating native Android/iOS/MacCatalyst controls, renders HTML for WASM, and draws on a Skia surface for GTK.
All the WinUI ported code (API contract) is mirrored by Uno in Uno.Core.dll and Uno.UI.dll
This means that in order to target a particular Uno platform code must be compiled for that platform.
Because:

1. WinUI compiled R3 looks for a WinUI contract in Windows.winmd and for Uno it is located in Uno.Core.dll and Uno.UI.dll
2. C# code generated from XAML to render UI is different for each platform
   However, R3 does not generate any XAML, and point 2 is not relevant for us. That is why we do not need to target net8.0-android and others, but just net8.0 to reference the Uno.Core.dll and Uno.UI.dll to redirect API calls. In this case, WinUI targets will use net8.0-windows10.x.xxxxx but Uno targets will use common net8.0

[neuecc]

I consider the current R3.WinUI to be generic support for WinUI, why doesn't Uno work with the current R3.WinUI3?
Is it because WinUI3 is now net6?

[xperiandri]

No, because WinUI uses managed to native interop and generates the code that looks for Microsoft.XAML namespaces in the Windows.winmd which is a native code file with .NET like metadata.
And Uno is completely managed .NET code. It is impossible to substitute native Windows API implementation at binary level.
That is why Uno has its own .NET DLLs that implement the same contract

[xperiandri]

And you cannot build WinUI for anything else than `netx.x-windows10.x.xxxxx’
As it enables that managed to native interop

[neuecc]

Understood, but I don't want to continue maintaining this csproj.
If you can introduce a better and cleaner approach, I will reconsider it at that time.

[xperiandri]

If you can introduce a better and cleaner approach

Could you define more measurable criteria?

[michaelstonis]

Uno just released support for a single project solution in 5.2, this might be better to revisit this and see if the changes needed for Uno can be better isolated.

[xperiandri]

@michaelstonis it was already 1 project here as it is a library.
I can make that csproj pretty small and look as usual.
Waiting for #188 to be approved