Update template so you can find it under Windows as well

[dotMorten]

Description of Change

When you filter project templates by Windows, it's almost as if MAUI isn't supported:

You have to select All platforms to see it, however it still works to filter by iOS, Android and MacOS, so this is inconsistent.

Also the WinUI category is misleading, as this is a MAUI app, and WinUI is just an underlying tech. As a user I'd prefer keeping the WinUI section for actual WinUI apps, and not get the groups too polluted.

PR Checklist

• Targets the correct branch
• Tests are passing (or failures are unrelated)
• Targets a single property for a single control (or intertwined few properties)
• Adds the property to the appropriate interface
• Avoids any changes not essential to the handler property
• Adds the mapping to the PropertyMapper in the handler
• Adds the mapping method to the Android, iOS, and Standard aspects of the handler
• Implements the actual property updates (usually in extension methods in the Platform section of Core)
• Tags ported renderer methods with [PortHandler]
• Adds an example of the property to the sample project (MainPage)
• Adds the property to the stub class
• Implements basic property tests in DeviceTests

Does this PR touch anything that might affect accessibility?

• Does this PR introduce a new control? (If yes, add an example using SemanticProperties to the SemanticsPage)
• APIs that modify focusability?
• APIs that modify any text property on a control?
• Does this PR modify view nesting or view arrangement in anyway?
• Is there the smallest possibility that your PR will change accessibility?
• I'm not sure, please help me

If any of the above checkboxes apply to your PR, then the PR will need to provide testing to demonstrate that accessibility still works.

[Eilon]

Should it say both WinUI and MacCatalyst? It's not purely an implementation detail in the sense that you can (and possibly might) write code that is WinUI-specific in that app.

Similarly, what about Mac Catalyst and macOS, for which it says both?

[dotMorten]

It's not purely an implementation detail

These categories are to help the user filter and find their templates. From a user workflow perspective, you'd use these dropdowns to look for specific types of project templates. If you're building a MAUI app, you'd pick MAUI, if you're starting a new WinUI app, you'd select that. I agree MacCatalyst is odd - I'd remove that. Seems like the odd one out in this list:

[rmarinho]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[Eilon]

@dotMorten your idea seems quite reasonable to me.

[mattleibow]

I think that list needs to be organised. You might want to filter by WinUI as that is the tech you want to use. Or the Mac Catalyst. That is different to macOS. Both are macOS, but maccat is a subset.

I suppose the argument for WinUI is that UI kit should be there too. The last drop down is project type and not platform.

@lutzroeder What should we do here? Do we have some set of things? I see Plugin and Other which makes me things everyone just puts what they want willy nilly.

[lutzroeder]

Is it possible to have both, and add Desktop and Mobile as well?

[Redth]

@BretJohnson is there a limit to the classifications a template can have? Is there any guidance on best practices here?

[phenning]

Instead of putting Windows in the classifications, which would cause it to show up as a "project type" (third combo in VS) rather than as a platform (the second one), it should be added to the ide.host.json as follows:

{
    "tags": [
        {
            "type": "platform",
             "add": [ "Windows" ]
        }
    ]
}

If we want it to show up as "Windows" in the CLI dotnet new list, you could also add it as a classification in template.json but then do the following in the host file to "move" it to the proper drop down within VS:

{
    "tags": [
        {
            "type": "platform",
             "add": [ "Windows" ]
        },
        {
            "type": "projectType",
             "remove": [ "Windows" ]
        }
    ]
}

[phenning]

In regards to my last comment, it looks like the IDE is doing some fix up when the VS template engine host passes what the IDE knows to be are "platforms" in as projectTypes. instead of adding it to the projectType drop down, it just treats the template as though it specified that platform tag instead. This also has the side effect of moving where the tag appears in the template detail.

For example, when using @dotMorten's technique:

When using the ide.host.json technique:

If specifying it both ways: