[Alexandre Zollinger Chohfi (azchohfi)]

This replaces #6824, which is now closed. The change is the same, recreated as one fresh commit on current main; its tree is identical to #6824's last head, 40ce46e8. That commit kept a stale failing check from the legacy ProjectReunion WindowsAppSDK-Templates-PR pipeline (since disabled), and closing and reopening #6824 didn't clear it. On that same tree, WinAppSDK-Foundation-PR passed 48/48 jobs and the current WindowsAppSDK-Templates-PR passed every stage.

Summary

Adds a Reactor Single-File App template to the Microsoft.WindowsAppSDK.WinUI.CSharp.Templates dotnet new pack, alongside the four Reactor templates from #6620. It scaffolds the blank Reactor (Microsoft.UI.Reactor) app as a single-file .NET 10 file-based app: one .cs file whose #:package / #:property directives replace the .csproj. This is the shape Reactor's getting-started guide documents under One file, no project (microsoft/microsoft-ui-reactor#1283).

Template	Short names	What it scaffolds
Reactor Single-File App (Experimental)	reactor-singlefile, winui-reactor-singlefile	The blank Reactor app as a single <name>.cs, with no .csproj, assets or manifest

dotnet new reactor-singlefile -n MyApp   # creates MyApp\MyApp.cs and nothing else
cd MyApp
dotnet run MyApp.cs                      # launches with package identity

The generated MyApp.cs with default parameters (the body is the same as the reactor blank app):

#:package Microsoft.UI.Reactor@0.1.0-preview.16
#:package Microsoft.WindowsAppSDK@*
#:package Microsoft.Windows.SDK.BuildTools.WinApp@*
#:property OutputType=WinExe
#:property TargetFramework=net10.0-windows10.0.26100.0
#:property UseWinUI=true

// A .NET file-based app: the #: directives above take the place of a .csproj.
// `dotnet run MyApp.cs` launches it with package identity (needs Developer Mode).
// To run it unpackaged instead, add `#:property WindowsPackageType=None` above.

using Microsoft.UI.Reactor;
// ...same usings and App component as ReactorBlankApp/App.cs...
ReactorApp.Run<App>("MyApp");

What changed

• dev/Templates/Source/ProjectTemplates/Desktop/CSharp/ReactorSingleFileApp/ProjectTemplate.cs is the whole template: the directive header above plus the ReactorBlankApp/App.cs body. sourceName renames it to <name>.cs, so the assembly name and the synthesized package identity follow the project name.
• dev/Templates/Dotnet/templates/reactor-singlefile-app/.template.config (template.json, dotnetcli.host.json, ide.host.json, icon.png):
  • Identity is Microsoft.WindowsAppSDK.Reactor.CSharp.SingleFileApp; classifications are Windows/WinUI/Desktop/Reactor/SingleFile/Experimental.
  • Parameters that carry over from the Reactor siblings keep the same names and defaults: --dotnet-version (net10.0), --reactor-version (0.1.0-preview.16), --wasdk-version (*, 2.2.0 or later), --windowsSdkBuildToolsWinAppVersion (*, 0.7.0 or later) and --no-restore.
  • The standard restore post action runs dotnet restore <name>.cs, which works on a .cs primary output.
• dev/Templates/templates.props:
  • A new reactor.singlefile row in the DotnetNewOnlyProjectTemplate slot.
  • A new, documented IncludeGitignore metadata value (default true). The new template sets it to false so its output stays a single file.
  • Also fixes the stale "no instances today" note on that slot.
• dev/Templates/Dotnet/WinAppSdk.CSharp.DotnetNewTemplates.csproj: the pack task skips the shared .gitignore when IncludeGitignore=false. Every other template's packed file list is unchanged.
• dev/Templates/Dotnet/README.md: adds a table row, a "Quickstart a single-file Reactor app" section, and a note on setting the WinAppRun* properties with #:property in a single-file app.
• dev/Templates/Dotnet/Test-DotnetNewTemplates.ps1: a minimal FileBasedApp kind, named after the .NET mechanism. It asserts that the scaffold is exactly <name>.cs, then runs dotnet build <name>.cs in the default (packaged) configuration.

Design notes

• Naming. The template is named single-file to match the only first-party dotnet new template for a .NET file-based app, Aspire's aspire-apphost-singlefile ("Aspire Single-File App Host", classification SingleFile). The descriptions and README keep the official .NET term file-based app, which also separates this from PublishSingleFile.
• Why it references Microsoft.WindowsAppSDK. With the published Microsoft.UI.Reactor 0.1.0-preview.16 alone, the Windows App SDK defaults to self-contained and the build fails with WindowsAppSDKSelfContained requires a supported Windows architecture. The Runtime dependency restored by Restore the Windows App Runtime dependency and document single-file apps microsoft-ui-reactor#1283 hasn't shipped yet. Referencing the metapackage, as the sibling templates do, makes the app framework-dependent and keeps --wasdk-version meaningful.
• Why WinApp 0.7.0 or later. Packaged dotnet run <file>.cs (Run a .NET file-based app with package identity winappCli#794, Support packaged dotnet run for .NET file-based apps winappCli#874) is new in Microsoft.Windows.SDK.BuildTools.WinApp 0.7.0. With 0.6.1, _WinAppRunSupportActive stays false, so dotnet run starts the unpackaged exe and the app fails at startup.
• What was left out of the siblings' setup.
  • The manifest is synthesized from the directives. Its display name is the file stem, which is the project name, just like the siblings' manifest.
  • So publisherDn, publisherDisplay, guid9 and the Windows SDK BuildTools pin were dropped. Microsoft.Windows.SDK.BuildTools comes in transitively.
  • Devtools are left out, because a #:package can't be Debug-only and file-based apps default to PublishAot=true.
  • Unlike the siblings' .csproj, there's no app.manifest, since Reactor sets PerMonitorV2 DPI awareness itself.
• Hidden from Visual Studio's New Project dialog. ide.host.json sets "unsupportedHosts": [{ "id": "vs" }], because a file-based app has no project for VS to open. The Aspire single-file template linked above does the same. The .NET CLI ignores ide.host.json, so dotnet new and winapp new are unaffected.
• Why the winui-reactor-singlefile alias. winapp new finds templates with dotnet new list winui, which matches names and short names only. Like the other Reactor templates, this one carries a winui-reactor* alias so winapp new --list and winapp new -t reactor-singlefile pick it up.

Validation

Local runs used .NET SDK 10.0.401, winapp 0.7.0 and Developer Mode, against the template pack packed from this change.

• Pack and install
  • dotnet pack: content/reactor.singlefile/ holds ProjectTemplate.cs plus the four .template.config files and no gitignore.txt. Compared with the published 0.0.7-alpha, the only content difference is those 5 new entries; the 10 sibling project templates still get their gitignore.txt.
  • dotnet new list winui and dotnet new list reactor both list Reactor Single-File App (Experimental) reactor-singlefile,winui-reactor-singlefile.
• Scaffold and build
  • dotnet new reactor-singlefile -n MyApp creates exactly MyApp\MyApp.cs and prints Restoring ...\MyApp\MyApp.cs: ... Restore succeeded..
  • dotnet build MyApp.cs in Debug and Release: 0 warnings, 0 errors.
  • Builds and runs write nothing next to the .cs file; the output goes to %TEMP%\dotnet\runfile\.
• Run
  • dotnet run MyApp.cs prints ✅ Manifest generated for MyApp-53b1794c 1.0.0.0 and then launched. The window titled "MyApp" opens, and GetPackageFullName on the process returns MyApp-53b1794c_1.0.0.0_x64__gspb8g6x97k2t (AUMID …!App). The package is a dev-mode registration with a dependency on Microsoft.WindowsAppRuntime.2 2.5.1.0.
  • Unpackaged: with #:property WindowsPackageType=None added, dotnet run opens the window, the process has no package identity (APPMODEL_ERROR_NO_PACKAGE), and nothing is registered.
  • winapp run MyApp.cs --detach launches the same identity.
  • #:property WinAppRunNoLaunch=true registers the app without launching it (checks the README note).
• dotnet publish MyApp.cs (Native AOT, the default for file-based apps)
  • Publishes to .\artifacts\MyApp\MyApp.exe with 0 warnings.
  • On my machine it only succeeds once %ProgramFiles(x86)%\Microsoft Visual Studio\Installer is on PATH. Without that, VS 18's vcvarsall fails with 'vswhere.exe' is not recognized. This is a toolchain environment issue, not a template one.
• winapp and pinned versions
  • winapp new --list --template-version installed lists Reactor Single-File App (Experimental) │ reactor-singlefile.
  • winapp new -t reactor-singlefile -n WinappApp scaffolds WinappApp\WinappApp.cs.
  • Pinning --wasdk-version 2.2.0 (the documented floor) builds with 0 warnings.
• Test script
  • Test-DotnetNewTemplates.ps1 -PackagePath <local nupkg> -SkipAppLaunch: All templates validated successfully. 41 summary rows are Succeeded: the 6 WinUI and 4 existing Reactor project templates, the new reactor-singlefile (create and build, where the build step first asserts the scaffold is a single file), the 7 item templates and the version scenarios. The one Skipped row is the default-wildcard build, which the script skips whenever * resolves to a concrete version.
  • Feed caveat: from my machine the repo's internal feed timed out (100 s) downloading the .NET 10.0.12 runtime packs, so a direct run failed on the first winui build before any Reactor template ran. That is a network problem on my end, not this change. The passing run used a byte-identical copy of the script whose generated NuGet.config points at a nuget.org proxy. The WindowsAppSDK-Templates-PR pipeline runs the script against the internal feed.

Follow-up (outside this repo)

• winapp new ends with Next: cd "<name>" then winapp run. For a single-file template that fails with Manifest file not found, because winapp run only enters single-file mode for an explicit .cs path. The correct command is winapp run <name>.cs (or dotnet run <name>.cs). That hint needs a fix in winappCli; this template's comments and the README already give the right command.
• When a single-file app runs packaged through winapp, two icons differ from the .csproj templates (Single-file (file-based) apps: taskbar icon drawn on accent plate and title bar icon missing winappCli#1077). The taskbar icon is drawn on an accent-colored plate, because the generated resources.pri doesn't index the unplated AppList* assets. The title bar has no icon, because the exe has no embedded .ico. Both need a fix in winapp; the template can't fix them without adding files next to the .cs.

---

A Microsoft employee must use /azp run to validate using the PR pipelines.

[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 1 pipeline(s).

[Alexandre Zollinger Chohfi (azchohfi)]

/azp run

[azure-pipelines]

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

[Niels Laute (niels9001)]

Tried this out locally next to the four Reactor .csproj templates (packed from this branch, WinApp 0.7.1, WASDK 2.5.1). reactor-singlefile scaffolds, builds and launches packaged as described. 🎉

Two visual differences compared to the .csproj templates, both on the winapp side rather than in this template:

1. Taskbar icon is drawn on an accent-colored plate. winapp writes Assets\AppList.targetsize-24_altform-unplated.png, but the generated resources.pri doesn't index any of the AppList* assets (no TARGETSIZE/ALTFORM qualifiers). So the shell falls back to the plated logo on the accent color.
2. No title bar icon. The .csproj templates embed Assets\AppIcon.ico through <ApplicationIcon>. The file-based app has no .ico, so the exe has no icon resource.

Tracking this in microsoft/winappCli#1077. We'll fix it there, so the template can stay a single file. I don't think this blocks the PR.

[Alexandre Zollinger Chohfi (azchohfi)]

Tracking this in microsoft/winappCli#1077. We'll fix it there, so the template can stay a single file.

Thanks for trying it next to the .csproj templates, and for filing the issue. Agreed, nothing to change in the template. I've added it to the follow-ups in the PR description.

[Alexandre Zollinger Chohfi (azchohfi)]

/azp run

[azure-pipelines]

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