Make Uno001 an error on Uno heads

[michael-hawker]

Describe the bug

It's easy to miss Uno001 errors about something not being supported on Uno Platform during development (as the warning window is usually a mess and easy to ignore).

We'd like to have a nice way to better highlight these issues before they get hit in the CI when warnings turn to errors.

However, we don't want to disrupt early prototyping by having these be blockers from running code.

In this regard, we feel a good solution is to have a middle-ground.

If you run the UWP or Windows App SDK heads, nothing should change.

If you run a WASM head, then Uno001's will be flagged as errors instead of warnings, thus you'll need to fix them to continue testing on Uno.

This provides an easy path to test and prototype and then a way to check and bubble up these issues locally easily before submitting to the CI.

Steps to reproduce

N/A

Expected behavior

Able to detect Uno001 issues more easily.

Screenshots

No response

Code Platform

• UWP
• WinAppSDK / WinUI 3
• Web Assembly (WASM)
• Android
• iOS
• MacOS
• Linux / GTK

Windows Build Number

• Windows 10 1809 (Build 17763)
• Windows 10 1903 (Build 18362)
• Windows 10 1909 (Build 18363)
• Windows 10 2004 (Build 19041)
• Windows 10 20H2 (Build 19042)
• Windows 10 21H1 (Build 19043)
• Windows 11 21H2 (Build 22000)
• Other (specify)

Other Windows Build number

No response

App minimum and target SDK version

• Windows 10, version 1809 (Build 17763)
• Windows 10, version 1903 (Build 18362)
• Windows 10, version 1909 (Build 18363)
• Windows 10, version 2004 (Build 19041)
• Other (specify)

Other SDK version

No response

Visual Studio Version

No response

Visual Studio Build Number

No response

Device form factor

No response

Additional context

We won't worry about this for other all-up heads for Uno until we focus on enabling those more easily later with work related to #17.

Help us help you

Yes, but only if others can assist.

[Arlodotexe]

Just one suggestion - we should open this to all Uno heads. Our components in Toolkit Labs and the Windows Toolkit only support UWP/WASDK/WASM for now, so there's no reason to restrict it.

Uno platform has different features implemented on each platform, which might raise Uno001 differently platform-to-platform.

[michael-hawker]

@Arlodotexe yup, for sure, just called out WASM here for now as that's the main one used for components and our focus for 8.0. Once we work on #17 and the like to more easily enable testing other Uno platforms, indeed we should follow a similar suit.

[Arlodotexe]

We only support UWP / WASDK / WASM at the moment, and no components have been built with explicit support for the other platforms afforded by Uno.

We'll have to update our default <MultiTarget> to just these 3 platforms (which is fine, I should have that done from the start), then people can start supporting other platforms as soon as we add the new heads and sort solution generation. We don't need to revisit this.

One less thing to do now, one less to think about later. I can't think of any issues we'd run into. Did I miss something?

[michael-hawker]

@Arlodotexe since we'll be looking at the Uno fork and comparing, I think it'll be safe to leave the multi-target as-is. Let people try things on other platforms and report issues or submit PRs. We'll just clearly document where we've tested things for which platforms, unless we know it doesn't explicitly support a platform and bad things happen or it's a lot of work.