tests(tfm): Improve tfm tests by using inline data

[DevTKSS]

GitHub Issue: closes #

PR Type:

• 🔄 Refactoring (no functional changes, no api changes)

What is the current behavior? 🤔

using only fact for the os specific tfm checks may be good for this specific task, but requires rewriting or changing current tested values

• the Test project and the check project itself had vulnurable dotnet package warnings

What is the new behavior? 🚀

• To be able to scale the tested cases and values also in future appearing issues, this added test introduces the option to "Just" add a InlineData line and check if the Parse Method is the culprit
• Updated the versions to the official released patched version (NO namespace changes or similar!)

PR Checklist ✅

Please check if your PR fulfills the following requirements:

• 📝 Commits must be following the Conventional Commits specification.
• 🧪 Added test (for bug fixes / features) (if applicable)
• 📚 Docs have been added/updated which fit documentation template (for bug fixes / features)
• 🖼️ Validated PR Screenshots Compare Test Run results.
  
• ❗ Contains NO breaking changes

Other information ℹ️

there are still left warnings that will make the ci fail but those are coming from the not longer supported net3.1+6 net version the check tool is targeting!

[DevTKSS]

@jeromelaban this is looking for review 👍

[Copilot]

Pull Request Overview

This PR refactors the TFM (Target Framework Moniker) tests to improve scalability and maintainability by introducing inline data-driven tests. The changes also update vulnerable NuGet package versions to their patched versions and add pragma warnings to suppress platform compatibility warnings.

• Introduced a new parametrized test method using [Theory] and [InlineData] attributes for easier test case management
• Updated NuGet package versions from 5.11.5 to 5.11.6 to address security vulnerabilities
• Added pragma warning suppressions for platform compatibility warnings in Windows-specific code

Reviewed Changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

File	Description
UnoCheck/Util.cs	Added pragma warning suppressions for platform compatibility warnings around Windows-specific code
UnoCheck/UnoCheck.csproj	Updated NuGet package versions from 5.11.5 to 5.11.6 to address vulnerabilities
UnoCheck.Tests/UnoCheck.Tests.csproj	Updated test framework package versions to latest versions
UnoCheck.Tests/CheckCommandTests.cs	Added new parametrized test method and improved existing test assertions

Comments suppressed due to low confidence (1)

UnoCheck.Tests/CheckCommandTests.cs:61

• The test assumes "net9.0-desktop" will always map to "win32" but this behavior may be OS-dependent like the existing tests. Consider adding OS-specific test cases or documenting why this assumption is valid.

    [InlineData(new string[] { "net9.0-android", "net9.0-ios", "net9.0-browserwasm", "net9.0-desktop"/*, "net9.0"*/}, new string[] { "android", "ios", "web", "win32" })]

[DevTKSS]

@jeromelaban just a thought: what do you think about using the <GenerateLibraryLayout>true</GenerateLibraryLayout> project tag — or alternatively <OutputType>Library</OutputType> — if we can parse them like the Tfm's?
Both are typically required anyway. But that way we could provide maybe Uno.Check capability to not file us all tfms by default like in real UI Client apps 💡

If a dedicated tag (similar to how we override Uno packages for prerelease scenarios) were introduced, we could explicitly signal whether all outputs, none, or a specific set should be included.

If this seems like a viable option, I’d be happy to create a separate PR for it.

[jeromelaban]

@jeromelaban just a thought: what do you think about using the true project tag — or alternatively Library — if we can parse them like the Tfm's?

I don't understand what you mean there. What's the intent?

[DevTKSS]

@jeromelaban currently Uno-check will complain about missing workloads as soon as we are creating a Uno.Sdk managed library project to use UnoFeatures and also if we have testing projects included which require our referenced/to-be-tested Uno UI project to also have this platform less target framework.

So all users who would not have everything installed just because they dont Target e.g. android or whatever, will constantly get prompted about problems found by uno-check and let me tell you, this is really annoying 😬🫤
Especially in business environments we don't have the permission maybe to install everything but we also don't have any options by now, to configure uno-check e.g. through global.json propertys (at least from what the docs introduced us to 🤷😅) like you could with a gh action or on azure functions equivalent.

So the idea was to make uno check runned through the vs extension for example configure-able if it finds the <OutputType>Library</OutputType>, just like we would do with a CLI command in the terminal:

• add global.json props
• make it consider a local dotnet-tools.json where we could "just" add our config to like skip checks x y z, or target/tfm a b c... -> potentially the cleanest and most realistic approach.
• add csproj tags for this (could maybe cause problems with release workflow, you will know better)