[Alexandre Zollinger Chohfi (azchohfi)]

Fixes three problems the dotnet new templates on main would ship in 0.0.8-alpha (#6953 bumped the version).

1. dotnet run warns on every packaged scaffold

Since #6905, packaged scaffolds of all nine app and test templates (winui, winui-mvvm, winui-navview, winui-tabview, winui-unittest, reactor, reactor-mvu, reactor-navview, reactor-tabview) get only "<name> (Package)" (commandName: MsixPackage). Without --launch-profile, dotnet run applies the first profile whose commandName is Project or Executable (dotnet/sdk LaunchSettings.ReadProfileSettingsFromFile). None qualifies, so every run prints the following before launching anyway:

The launch profile "(Default)" could not be applied.
A usable launch profile could not be located.

This restores the profile pair packaged scaffolds had before #6905. (Package) stays first, so it remains the Visual Studio F5 default, and (Unpackaged) (Project) follows it. dotnet run now applies (Unpackaged), and Microsoft.Windows.SDK.BuildTools.WinApp still launches the app with package identity. Unpackaged scaffolds are unchanged.

Known limitation, to be fixed separately. 0.0.7-alpha and the former VSIX templates had the same issue. For a Project profile, Visual Studio starts TargetPath directly and doesn't run ComputeRunArguments. Choosing (Unpackaged) on a packaged project in Visual Studio therefore starts the exe without package identity. The app then fails at startup with REGDB_E_CLASSNOTREG from the DeploymentManager auto-initializer.

2. The Reactor devtools profile passed a bare --devtools

Reactor reads a bare --devtools as --devtools run, which starts the devtools MCP-server session. The (Unpackaged, Devtools) profile now passes --devtools app. That only sets ReactorApp.DevtoolsEnabled, which DevtoolsMenu(...) and UseDevtools() read. The profile stays on unpackaged scaffolds only: dotnet run ignores a profile's commandLineArgs when the project sets RunArguments, and WinApp sets them for packaged apps. For packaged apps, use dotnet run -- --devtools app.

3. The Reactor csproj comment described a devtools menu that doesn't exist

The comment on the Debug-only ItemGroup said a "devtools F5 profile lights up the devtools menu". No template renders DevtoolsMenu(...), and packaged scaffolds had no such profile. The comment now says what the ItemGroup does. It references Microsoft.UI.Reactor.Devtools and turns on Reactor.DevtoolsSupport, which makes devtools available. Launching with --devtools app turns them on, and rendering DevtoolsMenu(...) shows the menu. (The XML comment says "the devtools "app" subcommand" because XML comments can't contain --.)

Test-DotnetNewTemplates.ps1 now checks that packaged scaffolds list MsixPackage first and include a Project profile, and that unpackaged Reactor scaffolds pass --devtools app (a bare --devtools fails the check). The template README describes the profiles and devtools.

Generated launch profiles

Scaffold	Profiles, in order
Packaged, all nine templates	<name> (Package): MsixPackage <name> (Unpackaged): Project
Unpackaged XAML apps and unit tests	<name> (Unpackaged): Project
Unpackaged Reactor apps	<name> (Unpackaged): Project <name> (Unpackaged, Devtools): Project, commandLineArgs: --devtools app

Validation

On .NET SDK 10.0.403, with the template pack installed into an isolated DOTNET_CLI_HOME and package cache:

• Packed the template project and scaffolded all nine templates, Packaged and Unpackaged. All 18 projects build for x64 Debug with 0 warnings and 0 errors.
• Ran dotnet run -c Debug -p:Platform=x64 on all 18. None printed a launch-profile warning. Packaged apps, winui-unittest included, ran with package identity (checked with GetPackageFullName); unpackaged apps ran without it. On main, the same command printed the warning for packaged winui and reactor scaffolds.
• Reactor (Unpackaged, Devtools): the app's command line ends in --devtools app, and no devtools MCP session starts. A bare --devtools prints [devtools] MCP serving on http://127.0.0.1:<port>/mcp.
• dotnet run -- --devtools app reaches all four packaged Reactor apps.
• Ran the script's Test-PackagingOptions locally on x64 for the eight app templates, including the unpackaged publish-and-launch smoke, and all passed. That run didn't use the script's Set-StrictMode -Version 2.0, so it missed a strict-mode error in the new profile-args check, which the first Templates-PR run caught. The second commit fixes it, and reactor and winui pass again under strict mode. The updated checks fail on main's profile sets.
• To confirm the Visual Studio limitation above, I launched a packaged scaffold's bin exe directly, as Visual Studio does for a Project profile. Both winui and reactor exited with 0xE0434352 (COMException 0x80040154 REGDB_E_CLASSNOTREG in DeploymentManagerAutoInitializer).

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

[Alexandre Zollinger Chohfi (azchohfi)]

/azp run

[azure-pipelines]

Azure Pipelines:
Successfully started running 2 pipeline(s).

[Alexandre Zollinger Chohfi (azchohfi)]

/azp run

[azure-pipelines]

Azure Pipelines:
Successfully started running 2 pipeline(s).