Full support for Uno Platform

[Arlodotexe]

Background

To keep things as easy as possible for our users, we want the Labs (and eventually, the Toolkit) to support:

• UWP - WinUI 1/2 (Windows)
• WinAppSDK - WinUI 3 (Windows)
• Uno Platform (all other platforms)

The problem

We're already multi-targeting between these 3 things. However, "Uno" isn't a standalone target framework, but rather a polyfill for WinUI and WinRT on many possible other platforms.

We're currently supporting Uno exclusively on WinUI 2 under WASM. This means any WinUI 2 projects using the toolkit won't need separate packages for Uno under their WASM head.

However, using Uno on WASM under WinUI 3 is not supported, as well as WinUI 2 on Android, WPF, iOS, MacOS, etc.

The solution

We need to investigate and add support for

• Multitargeting remaining Uno target frameworks, even if we don't use them for samples (though maybe we want sample projects for these, for testing?)
• Uno under both WinUI 2 and WinUI 3. This may involve conditionally including packages based on a flag other than the Framework version.

[Arlodotexe]

@michael-hawker If you have any comments or ideas related to multitargeting the remaining possible Uno targets, I'm all ears. Current setup only supports WinUI 2 under WASM if someone were to try using packages from Labs.

[Arlodotexe]

Note: recent work was done to support this, but a bug is present where the WINAPPSDK compilation constant isn't defined under Uno, even when the WinAppSDK is present.

Labs-Windows/Common/Labs.MultiTarget.props

Line 11 in 903b4cb

<DefineConstants Condition="'$(TargetFramework)' == 'net6.0-windows10.0.19041.0'">WINAPPSDK</DefineConstants>

[michael-hawker]

@Arlodotexe is this an Uno bug then that we should file on their repo?

[Arlodotexe]

@Arlodotexe is this an Uno bug then that we should file on their repo?

This is a lingering bug in the sample project system itself that I'll fix when closing this issue.

[michael-hawker]

Having talked to Jerome about Uno and where things are going. It seems our best bet is to still support two packages. I think it still makes sense to have our namespaces unified across the packages in order to facilitate easier updating and sharing of XAML between all platforms, otherwise that adds more complexity.

Therefore we should unify on the CommunityToolkit.WinUI.* namespace or in this case CommunityToolkit.Labs.WinUI.* for our experiments.

Then each experiment would have code-shared set of projects one for CommunityToolkit.Labs.UWP.* and another for CommunityToolkit.Labs.WinUI.*.

The UWP library would target UWP and Uno with WinUI 2.
The WinUI library will target WinAppSDK with WinUI 3 and Uno for WinUI 3.

This lets us support all the platforms with code that unifies on the namespace and allows for sharing of our XAML code as much as possible. This also means anyone working on UWP or WinUI 3 with Uno can just include the one package everywhere and be able to utilize it.

It still does leave us with a documentation problem though around having to explain which packages to use for UWP vs. WinUI 3.

I think the main concern is even though technically possible now to have a single package target UWP and WinUI 3, it may not stay that way, and all the dependencies in the ecosystem have already moved to having separate packages anyway. That makes the dependency tree a bit complex already.

[michael-hawker]

Writing down notes from our latest sync now that this is being looked at.

We agreed until the general naming schema issue is resolved here, we'll still plan to use UWP and WinUI as our package distinguishers here.

@Arlodotexe is also investigating if we can use a similar PowerShell switch to our target framework solution to switch between Uno.UI and Uno.WinUI to keep the experiment solution simple with a single head and spit out the packages instead in the CI.

Proposal

We'll end up with a single head in the experiment named CommunityToolkit.Labs.WinUI.ExperimentName, this will also use the same namespace. This should work for the UWP, WinAppSDK, and WASM heads in an individual experiment.

The CI will generate two packages:

• CommunityToolkit.Labs.WinUI.ExperimentName package for WinUI 3 + Uno.WinUI
• CommunityToolkit.Labs.UWP.ExperimentName package (but in the CommunityToolkit.Labs.WinUI.ExperimentName namespace) for WinUI 2 + Uno.UI

Challenges

I imagine this complicates the 'All' solution as the multi-targeted UWP/WinUI3/WASM assembly can't work across all projects heads. I would suggest that for #73 we probably have a toggle vs. trying to duplicate all the heads and have everything work for both at the same time, otherwise we'd have to figure out how to generate two separate packages automatically which we know with MSBuild would be difficult. Seems like the run a script and pick approach is going to continue to work best here.

TO DO

• Split CI into two pipelines (jobs)? One for UWP vs. WinUI identities?
• Add script to change Library targets between Uno.UI and Uno.WinUI (flag for CI to change package identity name? locally we don't care?)
• Have CI test each project in the correct environment for each pipeline
• Have CI package each proper package identity

@Arlodotexe I think that's the main breakdown, sound good? Anything I miss or any concerns?

[mrlacey]

Is this really closed?
There are unchecked TODO items.
#77 suggests that some things still don't work.