From 4a713d3ca77496ee03070725f611103962ec90c6 Mon Sep 17 00:00:00 2001 From: Alexandre Zollinger Chohfi Date: Tue, 6 Oct 2026 14:10:33 -0700 Subject: [PATCH] Correct Test-DotnetNewTemplates.ps1 comments that misdescribe app-template coverage Two comments in the template smoke test described behaviour the script does not have, both in the same direction: they implied the packaged path and `dotnet run` are covered when neither is. .DESCRIPTION claimed app templates "are optionally launched via dotnet run using the recommended WinAppSDK self-contained properties." Neither half is true. Launch-AppExecutables (line 265) resolves the built .exe under bin/ and Start-Process's it directly at line 277; `dotnet run` is never invoked. Builds pass -p:WindowsPackageType=None, which is the opposite of the self-contained packaged shape. The comment above the Reactor entries called those templates "unpackaged" and said "their .csproj already sets it" (WindowsPackageType). Both are wrong. The Reactor templates are packaged single-project MSIX apps: templates.props gives each one RenameManifestFrom=Package-managed.appxmanifest, and their ProjectTemplate.csproj sets EnableMsixTooling=true and no WindowsPackageType at all - the flag comes from the harness command line at line 372. That comment was never accurate rather than having drifted: 2fd73557 (#6620) introduced it in the same commit that added the templates, and at that commit all four ProjectTemplate.csproj files already declared EnableMsixTooling and no WindowsPackageType. It contradicted the templates it shipped with. This matters beyond tidiness. All nine Kind='App' templates ship a manifest and are built with packaging disabled, so Package.appxmanifest processing, MSIX tooling and identity activation are unexercised. Anyone auditing that coverage reads .DESCRIPTION, sees "launched via dotnet run", and stops. The comments were hiding the gap from the repo that owns it. No rationale for the flag is asserted here: none is recorded. It arrived with the harness in 9b5d40a61 (#6407), which added the file, so it was present from the first version rather than introduced later as a deliberate constraint. Comment-only; no behaviour change. Script parses with 0 errors. Line numbers above are as of this commit. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Separately, the comment-based help block opened with `<#+` instead of `<#`. That is a valid block comment to the parser, so the script always ran fine, but Get-Help could not recognise it as comment-based help: `Get-Help .\Test-DotnetNewTemplates.ps1` returned the auto-generated syntax line and no DESCRIPTION or PARAMETER text at all. Verified by copying the file to a scratch directory and changing only that token: as-is Get-Help reports no description, corrected it renders the full help including every .PARAMETER. That matters here because it is the reason the inaccurate .DESCRIPTION went unnoticed for so long - the corrected text would still have been invisible to anyone running Get-Help, which is how a PowerShell script is normally inspected. --- dev/Templates/Dotnet/Test-DotnetNewTemplates.ps1 | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/dev/Templates/Dotnet/Test-DotnetNewTemplates.ps1 b/dev/Templates/Dotnet/Test-DotnetNewTemplates.ps1 index 40036b6a8b..d27437622f 100644 --- a/dev/Templates/Dotnet/Test-DotnetNewTemplates.ps1 +++ b/dev/Templates/Dotnet/Test-DotnetNewTemplates.ps1 @@ -1,15 +1,17 @@ # Copyright (c) Microsoft Corporation. # Licensed under the MIT License. -<#+ +<# .SYNOPSIS Validates the WinUI 3 dotnet new template pack end-to-end. .DESCRIPTION Builds (or consumes) the template NuGet package, reinstalls it locally, and scaffolds every WinUI 3 project and item template. Each generated project is -built, and app templates are optionally launched via dotnet run using the -recommended WinAppSDK self-contained properties. +built; app templates build with -p:WindowsPackageType=None, so the packaged +(single-project MSIX) path is not exercised. When launching is enabled, app +templates are started directly from the built executable rather than via +dotnet run, so they run without MSIX package identity. .PARAMETER PackagePath Path to an existing Microsoft.WindowsAppSDK.WinUI.CSharp.Templates .nupkg. When @@ -680,9 +682,10 @@ try { # `dotnet test`. Validate it as an App so we still confirm the # template builds cleanly. @{ ShortName = 'winui-unittest'; Kind = 'App' }, - # Reactor (Microsoft.UI.Reactor) app templates: pure C#, unpackaged, - # dotnet-new-only. They build with the same App path below - # (-p:WindowsPackageType=None), and their .csproj already sets it. + # Reactor (Microsoft.UI.Reactor) app templates: pure C#, dotnet-new-only. + # Like the other app templates they are packaged (single-project MSIX), + # and they build through the same App path below, which passes + # -p:WindowsPackageType=None; the .csproj itself does not set it. @{ ShortName = 'reactor'; Kind = 'App' }, @{ ShortName = 'reactor-mvu'; Kind = 'App' }, @{ ShortName = 'reactor-navview'; Kind = 'App' },