Repository navigation
Reactor templates: drop the Microsoft.WindowsAppSDK metapackage reference - #6845
Merged
Alexandre Zollinger Chohfi (azchohfi) merged 5 commits intoNov 6, 2026
Conversation
…ence The Reactor dotnet-new templates referenced the full Microsoft.WindowsAppSDK metapackage, which also pulls in the AI, ML, Search, Widgets and DWrite components. Their native payload (onnxruntime.dll, DirectML.dll, ...) is copied into every app and can't be removed by trimming or Native AOT. Starting with Microsoft.UI.Reactor 0.1.0-preview.17 (microsoft/microsoft-ui-reactor#1283), Reactor depends on Microsoft.WindowsAppSDK.WinUI and Microsoft.WindowsAppSDK.Runtime, so the templates get a framework-dependent Windows App SDK transitively and no longer need their own reference. - Remove the Microsoft.WindowsAppSDK PackageReference from the four Reactor project templates. - Bump the default reactorVersion to 0.1.0-preview.17. - Remove the now-unused windowsAppSdkVersion / --wasdk-version parameter. - Stop passing --wasdk-version to Reactor templates in Test-DotnetNewTemplates.ps1. - Document the behavior in the dotnet-new README. Discussion: microsoft/microsoft-ui-reactor#1280 Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
|
Azure Pipelines: There may be pipelines that require an authorized user to comment /azp run to run. |
Resolve the README conflict with the new reactor-singlefile template (#6844), keeping its quickstart pointer and dropping the --wasdk-version mention. Apply the same change to reactor-singlefile that this PR makes to the other Reactor templates: remove the `#:package Microsoft.WindowsAppSDK` directive and the windowsAppSdkVersion / --wasdk-version parameter, and default reactorVersion to 0.1.0-preview.17, which carries Microsoft.WindowsAppSDK.Runtime. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
…lates Resolve conflicts with #6874 (templates moved under Dotnet/templates) and #6905 (Packaged/Unpackaged option, host-conditional package references): - ProjectTemplate.csproj: take main's layout, minus the HostIdentifier-gated Microsoft.WindowsAppSDK reference. - ide.host.json: take main's Packaging/publisher entries, minus the hidden windowsAppSdkVersion entry. - template.json: drop the new post-action that ran `dotnet add package Microsoft.WindowsAppSDK`, which would otherwise re-add the metapackage after scaffolding. - Test-DotnetNewTemplates.ps1: Test-PackagingOptions no longer passes --wasdk-version to reactor* templates, which no longer define it. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Morten Nielsen (dotMorten)
approved these changes
Nov 5, 2026
…ates Resolve conflicts with #6930 (Reactor templates enabled in Visual Studio) and #6885 (MTP test runner and unpackaged options for the unit test template): - ide.host.json (blank, mvu, navigation, tabview): take main's hidden version/restore entries, minus windowsAppSdkVersion, which these templates no longer define. Also drop the entry #6930 added to reactor-singlefile. - Test-DotnetNewTemplates.ps1: keep main's test-runner/packaging arguments and still skip --wasdk-version for reactor* templates. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Alexandre Zollinger Chohfi (azchohfi)
marked this pull request as ready for review
November 5, 2026 21:54
Contributor
Author
|
/azp run |
|
Azure Pipelines: Successfully started running 2 pipeline(s). |
Morten Nielsen (dotMorten)
approved these changes
Nov 5, 2026
Alexandre Zollinger Chohfi (azchohfi)
deleted the
azchohfi-templates-reference-winui-runtime-packag
branch
November 6, 2026 01:23
This was referenced Nov 6, 2026
Alexandre Zollinger Chohfi (azchohfi)
added a commit
to microsoft/microsoft-ui-reactor
that referenced
this pull request
Nov 11, 2026
…ce (#1465) * Describe Windows App SDK template pack 0.0.8-alpha in docs and guidance The next Windows App SDK template pack (microsoft/WindowsAppSDK#6845) adds a reactor-singlefile template and a --packaging Packaged|Unpackaged option, and its Reactor scaffolds no longer reference the Microsoft.WindowsAppSDK metapackage (--wasdk-version is gone). Launch profiles now follow the packaging mode. Update the Getting Started and Packaging guides, README, SKILL.md, the agent plugin, and bootstrap.ps1's closing guidance to match, and assert reactor-singlefile in the bootstrap workflow. Bootstrap only names reactor-singlefile when the installed pack provides it, because it keeps an already-installed older pack. Must not merge until the pack is on NuGet.org. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> * Point the getting-started skill at --devtools app, not the Devtools profile A bare --devtools is parsed as --devtools run (DevtoolsCliParser.ParseSubverbAfter), which starts the devtools logger and MCP server rather than only enabling the in-app dev menu. The Unpackaged scaffold's "(Unpackaged, Devtools)" profile passes exactly that, so the skill now matches #1464: run `dotnet run -- --devtools app` for the dev menu, and don't pick that profile just for it. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> * Warn instead of failing on reactor-singlefile before pack 0.0.8 The Verify step asserted reactor-singlefile unconditionally, so it failed on every run until template pack 0.0.8-alpha is the newest on NuGet.org: it checked the pack's release date rather than what bootstrap installed. Read the installed pack's version and require the template only from 0.0.8 on; an older pack gets a warning annotation, and an unreadable version fails closed. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> * Address pr-review findings - bootstrap.ps1: run the closing reactor-singlefile probe under a block-scoped 'Continue'. With no match, `dotnet new list` writes to stderr and exits 103. Windows PowerShell 5.1 turns redirected native stderr into error records, which the script-wide 'Stop' made terminating, so bootstrap died with exit 1 after "Bootstrap complete." on every machine whose pack predates reactor-singlefile. - BootstrapExitCode.Tests.ps1 case 9: run the probe's own statements, lifted from the AST, against dotnet.cmd shims on both legs. The match/no-match pair is a differential check, and on 5.1 the pre-fix line is the positive control. - Agent-facing guidance (root SKILL.md, reactor-getting-started skill, reactor-dev agent): say how to update a pack that predates `--packaging` and reactor-singlefile, matching the getting-started guide. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> * Address review round 1 A reactor-singlefile scaffold reached the reactor-dev agent's steps 4-5, which assume App.cs and a bare `mur check`. That runs `dotnet build .`, which needs a project file, so it exited 1 with no output even on an untouched scaffold. The agent's steps 4-5 and the reactor-getting-started single-file paragraph now say to keep all code in <Name>.cs and to check it with `mur check <Name>.cs`. Measured on a reactor-singlefile scaffold from the next pack, on SDKs 10.0.403 and 11.0.100-rc.3: - `mur check <Name>.cs` exits 0. - An injected typo gives CS0103 plus a did-you-mean hint, exit 1. - A sibling .cs file is not compiled in (CS0103). Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> * Address review round 2 `dotnet run -- --devtools app` does not light up a dev menu by itself. It only sets ReactorApp.DevtoolsEnabled, which is read only by UseDevtools() and DevtoolsMenu(...), and no Reactor template renders the menu (0 of 4 in the published 0.0.7-alpha, 0 of 5 in the next pack). The reactor-getting-started skill now uses #1464's wording: run with `--devtools app` and render DevtoolsMenu(...), because the flag alone draws nothing. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> * Describe the launch profiles from microsoft/WindowsAppSDK#6954 The next pack's launch profiles follow microsoft/WindowsAppSDK#6954, the set the user chose: - Packaged scaffolds list (Package) first, Visual Studio's F5 default, then (Unpackaged). - Unpackaged scaffolds keep (Unpackaged) and (Unpackaged, Devtools). The Devtools profile now passes `--devtools app`, so the old caveat against picking it for the dev menu is gone. The reactor-getting-started skill now also says: - `dotnet run` picks (Unpackaged) on a packaged scaffold, because it skips the MSIX profile, and WinApp still launches with package identity. - Under `dotnet run`, a packaged scaffold ignores profile arguments, so devtools come from `dotnet run -- --devtools app`. - Visual Studio users should keep (Package). (Unpackaged) starts a packaged scaffold without identity, and it fails with REGDB_E_CLASSNOTREG. Checked against #6954's diff (all four Reactor templates make the same change) and dotnet/sdk: the default profile is the first one with a supported commandName, and profile commandLineArgs apply only when the command has no arguments. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> * Verify against the published 0.0.8-alpha template pack Published 0.0.8-alpha (WindowsAppSDK bdc0deb7) also scaffolds AGENTS.md and .vscode/ in every project template, so list them with the other scaffold files in both SKILL.md copies. Bootstrap CI now installs 0.0.8-alpha, so the reactor-singlefile assertion no longer needs its pre-ship version gate. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> --------- Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
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.
Why
Follow-up to microsoft/microsoft-ui-reactor#1280. The Reactor
dotnet newtemplates referenced the fullMicrosoft.WindowsAppSDKmetapackage. That package also pulls in AI, ML, Search, Widgets and DWrite. Their native DLLs (onnxruntime.dll,DirectML.dll, …) get copied into every app, and trimming and Native AOT can't remove native files.Starting with 0.1.0-preview.17 (microsoft/microsoft-ui-reactor#1283),
Microsoft.UI.Reactordepends onMicrosoft.WindowsAppSDK.WinUI+Microsoft.WindowsAppSDK.Runtime. Apps get a framework-dependent Windows App SDK through that dependency, so the templates don't need their own reference.Changes
Microsoft.WindowsAppSDKreference from all five Reactor templates: the<PackageReference>inreactor-blank-app,reactor-mvu-app,reactor-navigation-appandreactor-tabview-app, and the#:packagedirective inreactor-singlefile-app.dotnet add package Microsoft.WindowsAppSDK(from Add packaging options to .NET WinUI and Reactor templates #6905) in the four project-based Reactor templates. Otherwise it would add the metapackage back after scaffolding.reactorVersionfrom0.1.0-preview.16to0.1.0-preview.17.windowsAppSdkVersion/--wasdk-versionparameter from the Reactor templates (template.json,dotnetcli.host.json,ide.host.json) because nothing uses it now.Test-DotnetNewTemplates.ps1: stopped passing--wasdk-versiontoreactor*templates in bothTest-WinUiProjectTemplateandTest-PackagingOptions.Dotnet/README.md: documented the behavior and how to add other Windows App SDK components.The WinUI (XAML) templates are unchanged.
Measurements
Test setup:
dotnet new winui, .NET SDK 10.0.401, win-x64, packages matching nuget.org latest (meta 2.5.1 → WinUI 2.3.9, Runtime 2.5.1)..exeReactor template (
reactor) trimmed publish: 73.3 MB → 33.9 MB.What this means for the questions in the discussion:
onnxruntime.dll21.7 MB,DirectML.dll18.7 MB,Microsoft.Windows.AI.MachineLearning.dll).Validation
main), installed it into an isolated hive, and scaffolded every Reactor template: the 4 project templates in both Packaged and Unpackaged modes, plus the single-file template. None references the metapackage, all default to preview.17, and--wasdk-versionis now rejected.Microsoft.WindowsAppSDK.WinUI>= 2.2.1,Microsoft.WindowsAppSDK.Runtime>= 2.2.0 andMicrosoft.Windows.SDK.BuildTools.MSIX>= 1.7.260930100. The local validation used preview.16 plus those packages, since the internal feed hadn't mirrored preview.17 yet.Test-UnpackagedPublishchecks (.exe,.pri,Assets\AppIcon.ico). The app opens its window and stays running.dotnet runregisters with aMicrosoft.WindowsAppRuntime.2dependency and the main window appears.onnxruntime.dllorDirectML.dll.Notes for reviewers
Windows App SDK version: apps now get the Windows App SDK version Reactor was built against (2.2.x today), not the latest (
*→ 2.5.1).Microsoft.WindowsAppSDK.Runtimerequires every referenced component to match its version exactly. So upgrading Windows App SDK on its own means referencing the matching metapackage or matching component versions. The README covers this.WinUI XAML templates (out of scope): these could make the same switch, but there are two problems:
--wasdk-versioncan't pin both.InteractiveExperiences >= 2.1.8, which was never published. That causes an NU1603 warning in a new project.I'll handle the XAML templates separately.