Repository navigation
Correct Test-DotnetNewTemplates.ps1 comments that misdescribe app-template coverage - #6846
Merged
Alexandre Zollinger Chohfi (azchohfi) merged 3 commits intoOct 21, 2026
Conversation
|
Azure Pipelines: There may be pipelines that require an authorized user to comment /azp run to run. |
3 of 4 tasks
Contributor
Author
|
/azp run |
Alexandre Zollinger Chohfi (azchohfi)
enabled auto-merge (squash)
October 6, 2026 21:20
|
Azure Pipelines: Successfully started running 1 pipeline(s). |
Lauren Ciha (lauren-ciha)
approved these changes
Oct 6, 2026
Member
|
/azp run |
|
Azure Pipelines: Successfully started running 2 pipeline(s). |
…plate 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: 2fd7355 (#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 9b5d40a (#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.
Lauren Ciha (lauren-ciha)
force-pushed
the
azchohfi-fix-template-harness-help-comments
branch
from
October 15, 2026 22:17
4889d6e to
4a713d3
Compare
Member
|
/azp run |
|
Azure Pipelines: Successfully started running 2 pipeline(s). |
Member
|
/azp run |
|
Azure Pipelines: Successfully started running 2 pipeline(s). |
Contributor
Author
|
/azp run |
|
Azure Pipelines: Successfully started running 2 pipeline(s). |
Alexandre Zollinger Chohfi (azchohfi)
deleted the
azchohfi-fix-template-harness-help-comments
branch
October 21, 2026 16:48
Lauren Ciha (lauren-ciha)
pushed a commit
that referenced
this pull request
Oct 21, 2026
…plate coverage (#6846) 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: 2fd7355 (#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 9b5d40a (#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.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Supersedes #6805 (byte-identical content, fresh branch for a clean CI run). Comment-only — no behaviour change to what the script builds or runs.
1.
.DESCRIPTIONdescribed coverage the script doesn't haveIt claimed app templates "are optionally launched via dotnet run using the recommended WinAppSDK self-contained properties." Neither half is true:
Launch-AppExecutablesresolves the built.exeunderbin/andStart-Processes it directly.dotnet runis never invoked.-p:WindowsPackageType=None, which is the opposite of the self-contained packaged shape.2. The Reactor comment was false from the commit that wrote it
It called those templates "unpackaged" and said "their .csproj already sets it" (
WindowsPackageType). Both wrong — and not drift:2fd73557(#6620) added the comment and the templates in the same commit, and at that commit all fourProjectTemplate.csprojfiles already declaredEnableMsixTooling=truewith noWindowsPackageTypeelement. It contradicted the templates it shipped with.templates.propsalso gives each oneRenameManifestFrom=Package-managed.appxmanifest.3.
<#+suppressed comment-based help entirelyThe help block opened with
<#+instead of<#. That is a valid block comment to the parser, so the script always ran fine — butGet-Helpdid not recognise it as comment-based help and returned the auto-generated syntax line with noDESCRIPTIONorPARAMETERtext.Verified by copying the file to a scratch directory and changing only that token:
Get-Helpoutput<#+(before)<#(after).PARAMETERThis is why the inaccurate
.DESCRIPTIONwent unnoticed: correcting the text alone would still have left it invisible to anyone inspecting the script the normal way. Fixing the opener also surfaces the existing-SkipAppLaunch,-Platforms,-RunTimeoutSecondsetc. help for the first time.Why this matters beyond tidiness
All nine
Kind='App'templates ship a manifest and are built with packaging disabled, soPackage.appxmanifestprocessing, 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
-p:WindowsPackageType=Noneis asserted here, in either direction — none is recorded. It arrived with the harness in9b5d40a61(#6407), the commit that added the file, so it was present in the first version rather than introduced later as a deliberate constraint. Rather than invent a plausible justification, this PR just makes the description match observable behaviour.Validation
[Parser]::ParseFile).Get-Helprenders the corrected description and all parameter help.6f1f0cc9),WindowsAppSDK-Templates-PRran in full and "Smoke-test dotnet new templates / Scaffold and build dotnet new templates" passed — that is the stage which actually executes this script.Known unrelated CI failure
On #6805 the only failing stage was "Validate VSIX templates build / Restore + build WindowsAppSDK.Extension.sln". That stage fails identically on unrelated PRs #6843, #6835 and #6824, so it is a pre-existing repo-wide failure rather than anything introduced here — a comment-only edit to a
.ps1cannot affect a VSIX solution build. Expect it to fail here too until it is fixed centrally.