Repository navigation
Fix errors from missing resource dll with version info - #6725
Merged
Merged
Conversation
Treat an absent aggregate runtime resource as an unavailable version instead of failing component-only applications. Preserve loader errors for present or required resources and document the zero and empty fallback values. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Treat ERROR_MOD_NOT_FOUND directly as an unavailable aggregate runtime resource. The resource DLL has only supported Windows system dependencies, so an additional data-file load probe is unnecessary. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Treat a missing aggregate runtime resource as evidence of component-only self-contained deployment. Keep other package-family lookup failures intact and cover the missing-resource path. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Allow TAEF to load the test module before the fixture adds the runtime framework package to the package graph. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Clear the bootstrap test package-family override while validating component-only detection, then restore it to keep the fixture isolated. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Document why the bootstrap package-family override is cleared and restored around the missing-resource assertion. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
When aggregate version resources are unavailable, identify framework deployment from the runtime module's framework package location. Cache absent framework resources and preserve packaged self-contained classification. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Restore the aggregate runtime resource as the deployment-model signal and keep the missing-resource handling focused in IsSelfContained. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Manodasan Wignarajah (manodasanW)
requested a review
from Scott Jones (Scottj1s)
August 27, 2026 21:28
|
Azure Pipelines: There may be pipelines that require an authorized user to comment /azp run to run. |
Member
Author
|
/azp run |
|
Azure Pipelines: Successfully started running 2 pipeline(s). 1 pipeline(s) were filtered out due to trigger conditions. |
Scott Jones (Scottj1s)
approved these changes
Sep 2, 2026
Member
Author
|
/azp run |
|
Azure Pipelines: Successfully started running 2 pipeline(s). 1 pipeline(s) were filtered out due to trigger conditions. |
Manodasan Wignarajah (manodasanW)
enabled auto-merge (squash)
September 2, 2026 20:27
Scott Jones (Scottj1s)
added a commit
that referenced
this pull request
Sep 3, 2026
This was referenced Sep 18, 2026
Manodasan Wignarajah (manodasanW)
added a commit
that referenced
this pull request
Sep 23, 2026
…ersion info (#6725) (#6776) * Fix errors from missing resource dll with version info (#6725) * Add containment for missing VersionInfo resource DLL Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: b827f915-8160-4a92-84cc-c42ce5d787a8 * Deploy FrameworkUdk for VersionInfo tests on RS5 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: b827f915-8160-4a92-84cc-c42ce5d787a8 --------- Copilot-Session: b827f915-8160-4a92-84cc-c42ce5d787a8
Kyaw Thant (kythant)
added a commit
that referenced
this pull request
Oct 2, 2026
….0-stable (#6830) * Update dependencies from https://dev.azure.com/microsoft/LiftedIXP/_git/DCPP build 20260622.2 On relative base path root Microsoft.FrameworkUdk , Microsoft.ProjectReunion.InteractiveExperiences.TransportPackage From Version 2.0.0-stable-27200.1029.260616-0840.3 -> To Version 2.0.0-stable-27200.1030.260622-0700.1 Microsoft.WindowsAppSDK.InteractiveExperiences From Version 2.0.16-stable-Rolling.20260617.1 -> To Version 2.0.16-stable-Rolling.20260622.2 * Update dependencies from https://dev.azure.com/microsoft/LiftedIXP/_git/DCPP build 20260629.1 On relative base path root Microsoft.FrameworkUdk , Microsoft.ProjectReunion.InteractiveExperiences.TransportPackage From Version 2.0.0-stable-27200.1029.260616-0840.3 -> To Version 2.0.0-stable-27200.1031.260629-0710.0 Microsoft.WindowsAppSDK.InteractiveExperiences From Version 2.0.16-stable-Rolling.20260617.1 -> To Version 2.0.16-stable-Rolling.20260629.1 * Update dependencies from https://dev.azure.com/microsoft/LiftedIXP/_git/DCPP build 20260630.1 On relative base path root Microsoft.FrameworkUdk , Microsoft.ProjectReunion.InteractiveExperiences.TransportPackage From Version 2.0.0-stable-27200.1029.260616-0840.3 -> To Version 2.0.0-stable-27200.1032.260629-2200.0 Microsoft.WindowsAppSDK.InteractiveExperiences From Version 2.0.16-stable-Rolling.20260617.1 -> To Version 2.0.16-stable-Rolling.20260630.1 * [2.0 Servicing] Fix UniversalBGTask crash and gracefully handle CoCreateInstance failures (#6568) * Fix UniversalBGTask crash and gracefully handle CoCreateInstance failures (#6507) UniversalBGTask::Task::Run could crash backgroundTaskHost.exe in two scenarios: 1. When LocalSettings has no entry for the task's TaskId, ApplicationDataContainerSettings::Lookup returns S_OK with a null IInspectable. The subsequent unbox_value<guid> then throws hresult_no_interface, and because the broker treats the failure as transient it re-fires the trigger forever. 2. When CoCreateInstance fails (e.g. the COM class isn't registered against the package), the wrapped THROW_IF_FAILED produced no diagnostic context. Fix: - If LocalSettings.Lookup returns null, log via wil and unregister the orphaned OS task so the broker stops re-firing it. - If CoCreateInstance fails, log the HR with the CLSID and TaskId and return cleanly. The registration is left in place so the broker can retry on the next trigger in case the failure is transient. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * [2.0 Servicing] Add containment for UniversalBGTask::Task::Run crash fix (bug 62755661) Wrap the crash-hardening behavior behind WINAPPSDK_CHANGEID_62755661 (WinAppSDK_2_2_2) and add the RuntimeCompatibilityChange.UniversalBGTask_RunCrash enum entry so apps can opt out via RuntimeCompatibilityOptions. * Update dev/WindowsAppRuntime_UniversalBGTaskDLL/Task.cpp Co-authored-by: agniuks <41223743+agniuks@users.noreply.github.com> * [2.0 Servicing] Fix build break: import FrameworkUdk targets in UniversalBGTaskDLL Task.cpp now includes <FrameworkUdk/Containment.h> for the containment fix, but WindowsAppRuntime_UniversalBGTaskDLL.vcxproj did not import the Microsoft.FrameworkUdk targets, so the FrameworkUdk include directory was missing from the compiler command line, causing: Task.cpp(10,10): error C1083: Cannot open include file: 'FrameworkUdk/Containment.h': No such file or directory Import Microsoft.FrameworkUdk.targets (which adds the include path and the Microsoft.Internal.FrameworkUdk.lib link dependency) plus the matching package-restore Error check, mirroring the existing pattern used by Microsoft.Windows.ApplicationModel.Resources.vcxproj and other Containment consumers. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: agniuks <41223743+agniuks@users.noreply.github.com> * Update dependencies from https://dev.azure.com/microsoft/LiftedIXP/_git/DCPP build 20260701.1 On relative base path root Microsoft.FrameworkUdk , Microsoft.ProjectReunion.InteractiveExperiences.TransportPackage From Version 2.0.0-stable-27200.1029.260616-0840.3 -> To Version 2.0.0-stable-27200.1033.260630-2330.0 Microsoft.WindowsAppSDK.InteractiveExperiences From Version 2.0.16-stable-Rolling.20260617.1 -> To Version 2.0.16-stable-Rolling.20260701.1 * Update dependencies from https://dev.azure.com/microsoft/LiftedIXP/_git/DCPP build 20260701.2 On relative base path root Microsoft.FrameworkUdk , Microsoft.ProjectReunion.InteractiveExperiences.TransportPackage From Version 2.0.0-stable-27200.1029.260616-0840.3 -> To Version 2.0.0-stable-27200.1033.260630-2330.1 Microsoft.WindowsAppSDK.InteractiveExperiences From Version 2.0.16-stable-Rolling.20260617.1 -> To Version 2.0.17 * [release/2.0-stable] Revert DCPP dependency updates to restore Version.Details.xml to #6513 state (#6592) * Revert "Update dependencies from https://dev.azure.com/microsoft/LiftedIXP/_git/DCPP build 20260617.1" This reverts commit 78720cd. * Revert "Update dependencies from https://dev.azure.com/microsoft/LiftedIXP/_git/DCPP build 20260609.1" This reverts commit 7a2bed8. * Revert "Update dependencies from https://dev.azure.com/microsoft/LiftedIXP/_git/DCPP build 20260605.2" This reverts commit 85f0069. * Revert "Update dependencies from https://dev.azure.com/microsoft/LiftedIXP/_git/DCPP build 20260602.3" This reverts commit b9c6dc6. * Keep Microsoft.FrameworkUdk at post-bump 260616-0840.3 so 1-arg IsChangeEnabled callsites compile The revert to #6513 downgraded FrameworkUdk to the pre-bump build, whose IsChangeEnabled template lacks the defaulted patchVersion param, breaking the 1-arg callsites in Helper.cpp and Task.cpp (C2672). Keep FrameworkUdk post-bump while leaving InteractiveExperiences reverted to 2.0.15 to fix the NuGet restore failure. * Update dependencies from https://dev.azure.com/microsoft/LiftedIXP/_git/DCPP build 20260705.3 On relative base path root Microsoft.FrameworkUdk From Version 2.0.0-stable-27200.1029.260616-0840.3 -> To Version 2.0.0-stable-27200.1034.260705-0915.2 Microsoft.ProjectReunion.InteractiveExperiences.TransportPackage From Version 2.0.0-stable-27200.1024.260527-1035.1 -> To Version 2.0.0-stable-27200.1034.260705-0915.2 Microsoft.WindowsAppSDK.InteractiveExperiences From Version 2.0.15 -> To Version 2.0.17-stable-Rolling.20260705.3 * Update dependencies from https://dev.azure.com/microsoft/LiftedIXP/_git/DCPP (#6594) Microsoft.FrameworkUdk: 2.0.0-stable-27200.1029.260616-0840.3 -> 2.0.0-stable-27200.1033.260630-2330.1 Microsoft.ProjectReunion.InteractiveExperiences.TransportPackage: 2.0.0-stable-27200.1024.260527-1035.1 -> 2.0.0-stable-27200.1033.260630-2330.1 Microsoft.WindowsAppSDK.InteractiveExperiences: 2.0.15 -> 2.0.17 * 230 enums * add CompositionEngine_API enum (62917618) * add 4 winui sweep enums * Update dependencies from https://dev.azure.com/microsoft/LiftedIXP/_git/DCPP build 20260708.3 On relative base path root Microsoft.FrameworkUdk , Microsoft.ProjectReunion.InteractiveExperiences.TransportPackage From Version 2.0.0-stable-27200.1033.260630-2330.1 -> To Version 2.0.0-stable-27200.1036.260708-1000.0 Microsoft.WindowsAppSDK.InteractiveExperiences From Version 2.0.17 -> To Version 2.0.17-stable-Rolling.20260708.3 * Update dependencies from https://dev.azure.com/microsoft/LiftedIXP/_git/DCPP build 20260708.4 On relative base path root Microsoft.FrameworkUdk , Microsoft.ProjectReunion.InteractiveExperiences.TransportPackage From Version 2.0.0-stable-27200.1033.260630-2330.1 -> To Version 2.0.0-stable-27200.1036.260708-1000.1 Microsoft.WindowsAppSDK.InteractiveExperiences From Version 2.0.17 -> To Version 2.0.17-stable-Rolling.20260708.4 * Update dependencies from https://dev.azure.com/microsoft/LiftedIXP/_git/DCPP build 20260709.2 On relative base path root Microsoft.FrameworkUdk , Microsoft.ProjectReunion.InteractiveExperiences.TransportPackage From Version 2.0.0-stable-27200.1033.260630-2330.1 -> To Version 2.1.0-stable-27200.1036.260708-1000.3 Microsoft.WindowsAppSDK.InteractiveExperiences From Version 2.0.17 -> To Version 2.1.1 * Update dependencies from https://dev.azure.com/microsoft/ProjectReunion/_git/WindowsAppSDKClosed build 2.0.0-stable.20260709.4 On relative base path root Microsoft.WindowsAppSDK.AppLicensingInternal.TransportPackage From Version 2.0.0-stable.20260423.1 -> To Version 2.0.0-stable.20260709.4 * Update dependencies from https://dev.azure.com/microsoft/LiftedIXP/_git/DCPP build 20260712.1 On relative base path root Microsoft.FrameworkUdk , Microsoft.ProjectReunion.InteractiveExperiences.TransportPackage From Version 2.1.0-stable-27200.1036.260708-1000.3 -> To Version 2.1.0-stable-27200.1037.260712-1330.0 Microsoft.WindowsAppSDK.InteractiveExperiences From Version 2.1.1 -> To Version 2.1.1-stable-Rolling.20260712.1 * Update dependencies from https://dev.azure.com/microsoft/LiftedIXP/_git/DCPP build 20260715.1 On relative base path root Microsoft.FrameworkUdk , Microsoft.ProjectReunion.InteractiveExperiences.TransportPackage From Version 2.1.0-stable-27200.1036.260708-1000.3 -> To Version 2.1.0-stable-27200.1038.260715-1144.0 Microsoft.WindowsAppSDK.InteractiveExperiences From Version 2.1.1 -> To Version 2.1.1-stable-Rolling.20260715.1 * Add WindowsServices_GetKeyboardModifiersStateRace enum (62927180) WinUI PR 16052384 (bug 62927180) merged the GetKeyboardModifiersState race fix into release/2.0-stable with containment gate WINAPPSDK_CHANGEID_62927180, but the corresponding RuntimeCompatibilityChange enum was missing from Foundation, leaving apps unable to opt out of the change. Add the enum in numeric order. * Add 62927180 to s_changes_2_3_0 catalog group Containment v2 (2.0 train) requires the catalog entry alongside the IDL enum. Fold WindowsServices_GetKeyboardModifiersStateRace (62927180) into s_changes_2_3_0[] in ascending order so RuntimeCompatibilityOptions::Apply's pre-prune walk covers it. * Update dependencies from https://dev.azure.com/microsoft/LiftedIXP/_git/DCPP build 20260716.1 On relative base path root Microsoft.FrameworkUdk , Microsoft.ProjectReunion.InteractiveExperiences.TransportPackage From Version 2.1.0-stable-27200.1036.260708-1000.3 -> To Version 2.1.0-stable-27200.1038.260715-1144.2 Microsoft.WindowsAppSDK.InteractiveExperiences From Version 2.1.1 -> To Version 2.1.3 * [2.0-stable] Gated cherry-pick: MrmGetFilePathFromName S_OK fallback (#6603) (#6612) * Cherry-pick MrmGetFilePathFromName S_OK fallback (gated) into release/2.0-stable Cherry-picks PR #6603 into release/2.0-stable, but gates the behavior change behind a RuntimeCompatibilityOptions containment check so apps can disable it. MrmGetFilePathFromName is documented to always succeed and return a best-effort path even when no PRI file exists. On 2.0-stable it fails with ERROR_FILE_NOT_FOUND, which makes `new ResourceManager()` throw when there is no resources.pri (the XAML-island / no-PRI scenario). Because this changes an HRESULT from a failure to S_OK, the change is contained under WINAPPSDK_CHANGEID_63048673: - Enabled (default): MrmGetFilePathFromName returns S_OK with a non-null best-effort path (the provided filename, else resources.pri) under the base directory (if set) otherwise the module directory. - Disabled (via RuntimeCompatibilityOptions): behavior reverts byte-for-byte to the current 2.0-stable behavior (ERROR_FILE_NOT_FOUND). Both terminal search passes jump to Final, skipping the DefaultFallback pass. Changes: - MRM.cpp: gate the reachable DefaultFallback pass + S_OK return on IsChangeEnabled<WINAPPSDK_CHANGEID_63048673>(). Add #include <FrameworkUdk/Containment.h> and an inline #define for the change ID, following the existing 62382643 precedent in Helper.cpp. Preserve the module directory since the parent-folder search mutates exeDir in place. - MRM.vcxproj: link the FrameworkUdk Containment worker (targets import + EnsureNuGetPackageBuildImports). - MrmUnitTest.vcxproj: deploy Microsoft.Internal.FrameworkUdk.dll next to the test host (mrm.dll now imports it). - Helper.cpp (GetDefaultPriFile): inside the existing 62382643 block, gate the sparse-packaged [modulename].pri fallback on actual file existence (CheckFile) so it still fires once MrmGetFilePathFromName returns S_OK. Correct whether 63048673 is enabled or disabled; preserves 62382643 behavior. - MrmTests.cpp: strengthen GetFilePath to assert the fallback path is under the module directory. - BypassTests.json: remove the now-passing UnitTest::BasicTest::GetFilePath and MrtCoreUnpackagedTests.TestClass.DefaultResourceManager entries so they gate. Note for release engineering: per the ContainmentV2 model this PR only defines and gates the change ID; associating 63048673 to a release group in RuntimeCompatibilityOptions.cpp's s_catalogGroupsProd[] is the separate branch-cut step. Verified locally (x64 Debug): MrmUnitTest 21/21 (change enabled by default). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Add unit test confirming pre-fix behavior when fallback change is disabled Adds ContainmentDisabledTest::GetFilePathFallbackDisabled to MrmUnitTest. It disables WINAPPSDK_CHANGEID_63048673 via the FrameworkUdk containment worker (WinAppSdk::Containment::SetConfiguration) and verifies MrmGetFilePathFromName reverts to the previous behavior: ERROR_FILE_NOT_FOUND (null path) for a non-existent PRI file, instead of S_OK with a best-effort path. The class uses IsolationLevel=Method so it runs in its own process. This is required because IsChangeEnabled<>() caches its result in a process-lifetime function-local static, so the disabled-state test must not share a process with BasicTest::GetFilePath (which exercises the enabled default state). MrmUnitTest.vcxproj: import the FrameworkUdk targets so the test can call the Containment worker (mrm.dll already imports Microsoft.Internal.FrameworkUdk.dll, deployed next to the test host). Verified locally (x64 Debug): MrmUnitTest 22/22, including both the enabled (GetFilePath) and disabled (GetFilePathFallbackDisabled) cases. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * [CP to 2.x] Fix focus not restored after Storage Pickers dialog closes (#6602) This is a cherry-pick of #6544 **Summary:** Issue reported in #6505. Storage Pickers leave the WinUI window without keyboard focus after their dialog closes, so the keyboard stops working until the user clicks the window again. **Repro:** 1. in code map a button's Click handler with a picker behavior. 2. Click the button (dialog opens), pick a file and confirm (dialog closes), 3. then press Enter. 4. Before the fix Enter does nothing; After the fix Enter re-invokes the button and the dialog reopens. **Fix:** An RAII helper `DialogFocusRestorer` captures the focused window before the dialog opens and restores focus to it once the dialog closes. Applied to all five pick methods. * [2.0-stable] Gated port: MICROSOFT_WINDOWSAPPRUNTIME_BASE_DIRECTORY child-process isolation (#5987) (#6632) * [2.0-stable] Gated port: MICROSOFT_WINDOWSAPPRUNTIME_BASE_DIRECTORY child-process isolation (#5987) Ports the base-directory PID-guard fix (main #6619) into release/2.0-stable, gated behind a runtime-compatibility containment change (WINAPPSDK_CHANGEID_63098302) so apps can revert. MICROSOFT_WINDOWSAPPRUNTIME_BASE_DIRECTORY is set by the Windows App SDK auto-initializer (a requirement for PublishSingleFile SxS manifest redirection). Because it is a process environment variable it is inherited by child processes spawned via CreateProcess, so a child's MRTCore resolved the parent's resources.pri and reg-free WinRT redirection could be steered by a parent-controlled directory. The setter now also stamps MICROSOFT_WINDOWSAPPRUNTIME_BASE_DIRECTORY_PID with the owning process id. Gated behind WINAPPSDK_CHANGEID_63098302 (ContainmentV2 form): - Enabled (default): MRM.cpp and catalog.cpp honor the base directory only when the stamp matches the current process; inherited (foreign) values fall back to the module directory. - Disabled (via RuntimeCompatibilityOptions): the base directory is honored regardless of the stamp (byte-for-byte prior behavior). Changes: - UndockedRegFreeWinRT-AutoInitializer.cs: stamp the owning process id (ungated; consumers ignore it when the change is disabled). - MRM.cpp: add WINAPPSDK_CHANGEID_63098302 and gate the base-directory PID guard. - catalog.cpp: gate the %MICROSOFT_WINDOWSAPPRUNTIME_BASE_DIRECTORY% strip on the change (WindowsAppRuntime_DLL already links the FrameworkUdk containment worker). - MrmTests.cpp: EnvironmentVariableIsolationTests (enabled: in-process guard + real cross-process insulation) and BaseDirectoryContainmentDisabledTest (IsolationLevel=Method; disables 63098302 and verifies the inherited base directory is honored). Verified locally (x64 Debug): MrmUnitTest 25/26 (1 skipped child-only worker), both enabled and disabled cases. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: dac4165f-ec13-4406-9206-60cd55b24c2b * catalog.cpp: only consult containment when the base-dir token is present (#5987) RCA of a PR-validation regression in CompatibilityTests (CanSetRuntimeCompatibilityOptions and VerifyDisabledChanges failing intermittently with E_ILLEGAL_STATE_CHANGE, "Configuration already set or locked"): WinAppSdk::Containment::IsChangeEnabled<>() locks the process's runtime-compatibility configuration on first call. catalog.cpp's WinRTLoadComponentFromString runs during reg-free WinRT activation - before an app (or test) can call RuntimeCompatibilityOptions.Apply(). Calling IsChangeEnabled unconditionally there locked the configuration early, so a subsequent Apply() failed. The manifest only references %MICROSOFT_WINDOWSAPPRUNTIME_BASE_DIRECTORY% for PublishSingleFile apps, so only consult the containment change when that token is actually present. Non-single-file activation (the common case, including CompatibilityTests) no longer calls IsChangeEnabled and no longer locks the configuration. MRTCore MrmUnitTest is unaffected (catalog.cpp is not in that binary). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: dac4165f-ec13-4406-9206-60cd55b24c2b --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Update dependencies from https://dev.azure.com/microsoft/LiftedIXP/_git/DCPP build 20260720.1 On relative base path root Microsoft.FrameworkUdk , Microsoft.ProjectReunion.InteractiveExperiences.TransportPackage From Version 2.1.0-stable-27200.1036.260708-1000.3 -> To Version 2.1.0-stable-27200.1040.260719-1733.1 Microsoft.WindowsAppSDK.InteractiveExperiences From Version 2.1.1 -> To Version 2.1.3-stable-Rolling.20260720.1 * Update dependencies from https://dev.azure.com/microsoft/LiftedIXP/_git/DCPP build 20260723.2 On relative base path root Microsoft.FrameworkUdk , Microsoft.ProjectReunion.InteractiveExperiences.TransportPackage From Version 2.1.0-stable-27200.1036.260708-1000.3 -> To Version 2.1.0-stable-27200.1041.260723-1213.1 Microsoft.WindowsAppSDK.InteractiveExperiences From Version 2.1.1 -> To Version 2.1.4-stable-Rolling.20260723.2 * Update dependencies from https://dev.azure.com/microsoft/LiftedIXP/_git/DCPP build 20260727.1 On relative base path root Microsoft.FrameworkUdk , Microsoft.ProjectReunion.InteractiveExperiences.TransportPackage From Version 2.1.0-stable-27200.1036.260708-1000.3 -> To Version 2.1.0-stable-27200.1042.260726-2015.0 Microsoft.WindowsAppSDK.InteractiveExperiences From Version 2.1.1 -> To Version 2.1.4-stable-Rolling.20260727.1 * 233 enums * Rename LanguageModel_LanguageDetectionStatus enum for naming consistency * Update dependencies from https://dev.azure.com/microsoft/LiftedIXP/_git/DCPP build 20260730.1 On relative base path root Microsoft.FrameworkUdk , Microsoft.ProjectReunion.InteractiveExperiences.TransportPackage From Version 2.1.0-stable-27200.1036.260708-1000.3 -> To Version 2.1.0-stable-27200.1043.260729-1713.0 Microsoft.WindowsAppSDK.InteractiveExperiences From Version 2.1.1 -> To Version 2.1.4-stable-Rolling.20260730.1 * reverting to stable * Update dependencies from https://dev.azure.com/microsoft/LiftedIXP/_git/DCPP build 20260802.2 On relative base path root Microsoft.FrameworkUdk , Microsoft.ProjectReunion.InteractiveExperiences.TransportPackage From Version 2.1.0-stable-27200.1038.260715-1144.2 -> To Version 2.1.0-stable-27200.1046.260802-1132.1 Microsoft.WindowsAppSDK.InteractiveExperiences From Version 2.1.3 -> To Version 2.1.5 * Fix CS0234 in UndockedRegFreeWinRT auto-initializer: qualify System.Globalization with global:: The auto-initializer ships inside the Microsoft.WindowsAppSDK.Foundation nuget and is compiled into consumer app projects under namespace Microsoft.Windows.Foundation.UndockedRegFreeWinRTCS. When the app also references the Microsoft.Windows.System namespace (e.g. EnvironmentManager or PowerManager), the unqualified leading 'System' in 'System.Globalization.CultureInfo' binds to Microsoft.Windows.System instead of the BCL System, producing: error CS0234: The type or namespace name 'Globalization' does not exist in the namespace 'Microsoft.Windows.System' This broke every C# sample in the Foundation official build. Prefix the reference with global:: so it always resolves to the BCL System namespace. This is the servicing equivalent of the main-branch fix #6633 (commit 37de565), which resolved the identical CS0234 after the base-directory child-process isolation change (#5987). The servicing port inlined the base-directory stamping into this file and did not carry the #6633 follow-up. * Update dependencies from https://dev.azure.com/microsoft/LiftedIXP/_git/DCPP build 20260804.1 On relative base path root Microsoft.FrameworkUdk , Microsoft.ProjectReunion.InteractiveExperiences.TransportPackage From Version 2.1.0-stable-27200.1038.260715-1144.2 -> To Version 2.1.0-stable-27200.1047.260804-0941.0 Microsoft.WindowsAppSDK.InteractiveExperiences From Version 2.1.3 -> To Version 2.1.5-stable-Rolling.20260804.1 * Update dependencies from https://dev.azure.com/microsoft/LiftedIXP/_git/DCPP build 20260806.1 On relative base path root Microsoft.FrameworkUdk , Microsoft.ProjectReunion.InteractiveExperiences.TransportPackage From Version 2.1.0-stable-27200.1038.260715-1144.2 -> To Version 2.1.0-stable-27200.1048.260805-2252.0 Microsoft.WindowsAppSDK.InteractiveExperiences From Version 2.1.3 -> To Version 2.1.5-stable-Rolling.20260806.1 * Update dependencies from https://dev.azure.com/microsoft/LiftedIXP/_git/DCPP build 20260806.2 On relative base path root Microsoft.FrameworkUdk , Microsoft.ProjectReunion.InteractiveExperiences.TransportPackage From Version 2.1.0-stable-27200.1038.260715-1144.2 -> To Version 2.1.0-stable-27200.1048.260805-2252.1 Microsoft.WindowsAppSDK.InteractiveExperiences From Version 2.1.3 -> To Version 2.1.6 * Update dependencies from https://dev.azure.com/microsoft/LiftedIXP/_git/DCPP build 20260813.1 On relative base path root Microsoft.FrameworkUdk , Microsoft.ProjectReunion.InteractiveExperiences.TransportPackage From Version 2.1.0-stable-27200.1038.260715-1144.2 -> To Version 2.1.0-stable-27200.1049.260812-1950.0 Microsoft.WindowsAppSDK.InteractiveExperiences From Version 2.1.3 -> To Version 2.1.6-stable-Rolling.20260813.1 * Update dependencies from https://dev.azure.com/microsoft/LiftedIXP/_git/DCPP build 20260824.1 On relative base path root Microsoft.FrameworkUdk , Microsoft.ProjectReunion.InteractiveExperiences.TransportPackage From Version 2.1.0-stable-27200.1038.260715-1144.2 -> To Version 2.1.0-stable-27200.1050.260824-0845.0 Microsoft.WindowsAppSDK.InteractiveExperiences From Version 2.1.3 -> To Version 2.1.7-stable-Rolling.20260824.1 * 242 enums * Update dependencies from https://dev.azure.com/microsoft/LiftedIXP/_git/DCPP build 20260826.2 On relative base path root Microsoft.FrameworkUdk , Microsoft.ProjectReunion.InteractiveExperiences.TransportPackage From Version 2.1.0-stable-27200.1038.260715-1144.2 -> To Version 2.1.0-stable-27200.1051.260826-1517.0 Microsoft.WindowsAppSDK.InteractiveExperiences From Version 2.1.3 -> To Version 2.1.7-stable-Rolling.20260826.2 * Update dependencies from https://dev.azure.com/microsoft/LiftedIXP/_git/DCPP build 20260827.1 On relative base path root Microsoft.FrameworkUdk , Microsoft.ProjectReunion.InteractiveExperiences.TransportPackage From Version 2.1.0-stable-27200.1038.260715-1144.2 -> To Version 2.1.0-stable-27200.1051.260826-1517.1 Microsoft.WindowsAppSDK.InteractiveExperiences From Version 2.1.3 -> To Version 2.1.8 * 250 enums * Update dependencies from https://dev.azure.com/microsoft/ProjectReunion/_git/WindowsAppSDKClosed build 2.0.0-stable.20260827.0 On relative base path root Microsoft.WindowsAppSDK.AppLicensingInternal.TransportPackage From Version 2.0.0-stable.20260709.4 -> To Version 2.0.0-stable.20260827.0 * [2.0-stable] Cherry-pick: Fix AppInstance process handle validation (#6733) (#6735) * Fix AppInstance process handle validation Open non-current processes with SYNCHRONIZE once and transfer the validated handle into AppInstance before registering the termination wait. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Potential fix for pull request finding Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> * Normalize AppInstance line endings Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: adb671f1-8cb1-4291-b25e-983d17a5bb1a * Contain GetInstances process handle fix * Keep GetInstances containment local * Fix AppInstance access mask narrowing conversion Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: c48ac29e-f034-4b5f-8ab5-dcd8da490048 --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> Copilot-Session: adb671f1-8cb1-4291-b25e-983d17a5bb1a Copilot-Session: c48ac29e-f034-4b5f-8ab5-dcd8da490048 * [2.x Servicing] Add new 'GetPackage[Graph]File` APIs (#6575) * MSIX FindPackageFile*() API (#6200) Implementation of MSIX FindPackageFile*() API Spec#5885 https://task.ms/59424502 NOTE: SearchStatic/DynamicDependencies options are dropped from spec because Windows doesn't expose this information. Get[Current]PackageInfo*() accepts an input to optionally filter package graph entries but output doesn't indicate if a package was statically or dynamically added to the package graph. * GetPackageFile() * Added Package activatable class to manifests * More tests. Added dev\common to various test projects' Include path to fix compile error. Cleaned up (optimized) several test projects. * Fixed missing build dependencies * Added TAEF VERIFY_* support for std::filesystem::path. More fixes and test updates * Fixed warnings * Fix to dynamically use GetPackagePathByFullName2 if available * Can't use RuntimeBehavior/TrustLevel on old pre-20H1 systems. Switched to classic EntryPoint=windows.fullTrustApplication via UUAP:AppXManifest=PackagedCwaFullTrust * Fixed Decimal and decimal test * Fixed GetPackagePathByFullName2IfSupported to work on RS5 * Incorporated feedback. Fixed telemetry * Fixed doc-comment typos --------- Co-authored-by: agniuks <41223743+agniuks@users.noreply.github.com> * [2.x Servicing][WASDK] Add new 'GetPackage[Graph]File` APIs * Fixed containment references * Fix IsPackageFeatureSupported and update RuntimeCompatibilityOptions for vNext servicing update * Gotta copy FrameworkUdk.dll to $(OutDir) to satisfy tests running on RS5 w/Containment --------- Co-authored-by: agniuks <41223743+agniuks@users.noreply.github.com> * [2.0-stable] Cherry-pick: AppNotificationManager::Show and AppInstanc… (#6773) * [2.0-stable] Cherry-pick: AppNotificationManager::Show and AppInstance::GetInstances noexcept workers (#6714) Cherry-pick of #6714 (Bug 61688595) onto release/2.0-stable, gated behind contained change 61688595 so the pre-change behavior is preserved when an app disables it via RuntimeCompatibilityOptions.DisabledChanges. AppNotificationManager::Show: the throwing body moves to ShowLegacy and is mirrored by a noexcept HRESULT worker (ShowImpl) that uses RETURN_HR_IF / RETURN_IF_FAILED / CATCH_RETURN. The public Show keeps the IsSupported() early-return, then either calls ShowLegacy (change disabled) or rethrows the worker's failure HRESULT via THROW_IF_FAILED(ShowImpl(...)) (change enabled). AppLifecycle::AppInstance::GetInstances: the body moves to GetInstancesWorker, wrapped by GetInstancesImpl(IVector<AppInstance>&) noexcept. The public GetInstances() calls the worker directly when the change is disabled, and THROW_IF_FAILED(GetInstancesImpl(...)) when it is enabled. The existing 63876312 process-handle containment inside the worker is unchanged. This keeps a failed HRESULT off the deep C++/WinRT projection rethrow path that exhausted the stack via WIL's FormatMessage-based exception logging chain. Tests: - CompatibilityTests: VerifyNoexceptHotPathsChangeEnabledByDefault and VerifyNoexceptHotPathsChangeCanBeDisabled cover the gate plumbing. - AppLifecycle FunctionalTests: GetInstancesIncludesCurrentInstance covers the refactored GetInstances boundary. - AppNotificationTests: VerifyShowToastTwiceFailsWithNotificationPosted covers Show still surfacing WPN_E_NOTIFICATION_POSTED. AB#61688595 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Fix AppLifecycle test crash on RS5/Server 2019: colocate FrameworkUdk GetInstancesIncludesCurrentInstance crashed the TAEF test host with 0xC06D007E (delay-load module not found) on x86 Server2019 and amd64 RS5. It is the first in-process AppLifecycle test to reach a WinAppSdk::Containment::IsChangeEnabled callsite, which delay-loads Microsoft.Internal.FrameworkUdk.dll. The delay-load resolver searches the app directory (TE.ProcessHost.exe's directory == the test output folder), and AppLifecycle.vcxproj was not copying that DLL there. On newer Windows the framework package graph resolved it anyway, which is why the failure only reproduced on the 1809-based legs. Copy Microsoft.Internal.FrameworkUdk.dll next to the test binary, matching the existing pattern in AppNotificationTests, LRPTests, EnvironmentManagerTests, CompatibilityTests and others. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 57737c8b-378d-4305-9111-cdf63ec2502f --------- Co-authored-by: Chris Wall (WIN SDE) <chriwall@microsoft.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 57737c8b-378d-4305-9111-cdf63ec2502f * [2.0-stable] Cherry-pick: Fix errors from missing resource dll with version info (#6725) (#6776) * Fix errors from missing resource dll with version info (#6725) * Add containment for missing VersionInfo resource DLL Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: b827f915-8160-4a92-84cc-c42ce5d787a8 * Deploy FrameworkUdk for VersionInfo tests on RS5 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: b827f915-8160-4a92-84cc-c42ce5d787a8 --------- Copilot-Session: b827f915-8160-4a92-84cc-c42ce5d787a8 * [57514396] Use central TSA config for Foundation source analysis (#6762) --------- Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com> Co-authored-by: Godly T.Alias <godlytalias@yahoo.co.in> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: agniuks <41223743+agniuks@users.noreply.github.com> Co-authored-by: agniuks <agnel@microsoft.com> Co-authored-by: Scott Jones <sjones@microsoft.com> Co-authored-by: Dinah Xiaoman G <116714259+DinahK-2SO@users.noreply.github.com> Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> Co-authored-by: Howard Kapustein <howardk@microsoft.com> Co-authored-by: Dreynor87 <wall_c.s@outlook.com> Co-authored-by: Chris Wall (WIN SDE) <chriwall@microsoft.com> Co-authored-by: Manodasan Wignarajah <mawign@microsoft.com> Co-authored-by: v-goradojcic <v-goradojcic@microsoft.com> Copilot-Session: adb671f1-8cb1-4291-b25e-983d17a5bb1a Copilot-Session: c48ac29e-f034-4b5f-8ab5-dcd8da490048 Copilot-Session: 57737c8b-378d-4305-9111-cdf63ec2502f Copilot-Session: b827f915-8160-4a92-84cc-c42ce5d787a8
Kyaw Thant (kythant)
added a commit
that referenced
this pull request
Oct 2, 2026
* Remove github-artifacts mcp server (#6684) * Remove github-artifacts mcp server * Update review prompts for GitHub MCP migration (#6686) Remove references to the retired github-artifacts helper and direct issue and PR review workflows to Copilot's standard web, file, and execution tools. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 2b34993b-0dcf-4789-94c5-97fd92cce84d --------- Co-authored-by: Gordon Lam <73506701+yeelam-gordon@users.noreply.github.com> Copilot-Session: 2b34993b-0dcf-4789-94c5-97fd92cce84d * MSIX: Always include PackageIntegrity/Content[Enforcement=on] in VS project templates (#6613) * Bump VSIX build .NET SDK to 10.0.111 (security release) (#6699) * Pin .NET SDK to patched 10.0.111 (CG DOTNET-Security-10.0) Component Governance flags a vulnerable .NET SDK (10.0.101) against /global.json. That version string is not in the repo -- global.json has no "sdk" block at all, so builds resolve whatever SDK the agent image happens to carry, and CG attributes what it detects to the nearest manifest. Note "tools.dotnet" is a non-standard bootstrap field and does not govern SDK resolution; only an "sdk" block does. Pins sdk.version to 10.0.111 (runtime 10.0.11, 2026-08-11 security release). Staying in the 1xx feature band already used here avoids unrelated MSBuild/SDK/analyzer behavior changes. Also bumps BuildVSIX 10.0.110 -> 10.0.111 so an SDK satisfying the pin is actually installed -- rollForward only rolls forward, never backward. That is independently a security improvement: 10.0.110 carries runtime 10.0.10 and is one security release behind. Follows up #6624. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 5474160f-e555-4254-899b-783ad9211b71 * Remove root global.json SDK pin; scope PR to VSIX only The root global.json `sdk` block is a repo-wide floor for every dotnet/MSBuild invocation beneath it. Foundation/MRT/PREfast jobs install only .NET SDK 6.0.414 (matched to the shipping net6.0 / net6.0-windows10.0.19041.0 TFMs), and rollForward never rolls backward across majors -- so Microsoft.NET.Sdk became unresolvable and 10 CI jobs failed with MSB4236. Scoping this PR to the BuildVSIX 10.0.110 -> 10.0.111 bump only. The CG global.json remediation requires installing the pinned SDK in every job that restores under the root global.json, and will be handled separately. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 484c9277-ea15-4f85-a4a0-0429347ade48 --------- Co-authored-by: Vineeth Thomas Alex <vithoma@microsoft.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 5474160f-e555-4254-899b-783ad9211b71 Copilot-Session: 484c9277-ea15-4f85-a4a0-0429347ade48 * [main] Update dependencies from microsoft/LiftedIXP/DCPP (#6636) * Update dependencies from https://dev.azure.com/microsoft/LiftedIXP/_git/DCPP build 20260717.1 On relative base path root Microsoft.FrameworkUdk , Microsoft.ProjectReunion.InteractiveExperiences.TransportPackage From Version 3.0.0-experimental-27300.1896.260713-1015.0 -> To Version 3.0.0-experimental-27300.1897.260717-1605.0 Microsoft.WindowsAppSDK.InteractiveExperiences From Version 3.0.0-experimental-Rolling.20260713.2 -> To Version 3.0.0-experimental-Rolling.20260717.1 * Update dependencies from https://dev.azure.com/microsoft/LiftedIXP/_git/DCPP build 20260719.1 On relative base path root Microsoft.FrameworkUdk , Microsoft.ProjectReunion.InteractiveExperiences.TransportPackage From Version 3.0.0-experimental-27300.1896.260713-1015.0 -> To Version 3.0.0-experimental-27300.1898.260719-1733.0 Microsoft.WindowsAppSDK.InteractiveExperiences From Version 3.0.0-experimental-Rolling.20260713.2 -> To Version 3.0.0-experimental-Rolling.20260719.1 * Update dependencies from https://dev.azure.com/microsoft/LiftedIXP/_git/DCPP build 20260723.1 On relative base path root Microsoft.FrameworkUdk , Microsoft.ProjectReunion.InteractiveExperiences.TransportPackage From Version 3.0.0-experimental-27300.1896.260713-1015.0 -> To Version 3.0.0-experimental-27300.1899.260723-1213.0 Microsoft.WindowsAppSDK.InteractiveExperiences From Version 3.0.0-experimental-Rolling.20260713.2 -> To Version 3.0.0-experimental-Rolling.20260723.1 * Update dependencies from https://dev.azure.com/microsoft/LiftedIXP/_git/DCPP build 20260727.2 On relative base path root Microsoft.FrameworkUdk , Microsoft.ProjectReunion.InteractiveExperiences.TransportPackage From Version 3.0.0-experimental-27300.1896.260713-1015.0 -> To Version 3.0.0-experimental-27300.1900.260726-2015.1 Microsoft.WindowsAppSDK.InteractiveExperiences From Version 3.0.0-experimental-Rolling.20260713.2 -> To Version 3.0.0-experimental-Rolling.20260727.2 * Update dependencies from https://dev.azure.com/microsoft/LiftedIXP/_git/DCPP build 20260729.1 On relative base path root Microsoft.FrameworkUdk , Microsoft.ProjectReunion.InteractiveExperiences.TransportPackage From Version 3.0.0-experimental-27300.1896.260713-1015.0 -> To Version 3.0.0-experimental-27300.1901.260728-1900.0 Microsoft.WindowsAppSDK.InteractiveExperiences From Version 3.0.0-experimental-Rolling.20260713.2 -> To Version 3.0.0-experimental-Rolling.20260729.1 * Update dependencies from https://dev.azure.com/microsoft/LiftedIXP/_git/DCPP build 20260806.3 On relative base path root Microsoft.FrameworkUdk , Microsoft.ProjectReunion.InteractiveExperiences.TransportPackage From Version 3.0.0-experimental-27300.1896.260713-1015.0 -> To Version 3.0.0-experimental-27300.1902.260806-0506.0 Microsoft.WindowsAppSDK.InteractiveExperiences From Version 3.0.0-experimental-Rolling.20260713.2 -> To Version 3.0.0-experimental-Rolling.20260806.3 * Update dependencies from https://dev.azure.com/microsoft/LiftedIXP/_git/DCPP build 20260814.1 On relative base path root Microsoft.FrameworkUdk , Microsoft.ProjectReunion.InteractiveExperiences.TransportPackage From Version 3.0.0-experimental-27300.1896.260713-1015.0 -> To Version 3.0.0-experimental-27300.1903.260814-0918.0 Microsoft.WindowsAppSDK.InteractiveExperiences From Version 3.0.0-experimental-Rolling.20260713.2 -> To Version 3.0.0-experimental-Rolling.20260814.1 * Update dependencies from https://dev.azure.com/microsoft/LiftedIXP/_git/DCPP build 20260818.1 On relative base path root Microsoft.FrameworkUdk , Microsoft.ProjectReunion.InteractiveExperiences.TransportPackage From Version 3.0.0-experimental-27300.1896.260713-1015.0 -> To Version 3.0.0-experimental-27300.1904.260818-1237.0 Microsoft.WindowsAppSDK.InteractiveExperiences From Version 3.0.0-experimental-Rolling.20260713.2 -> To Version 3.0.0-experimental-Rolling.20260818.1 * Update dependencies from https://dev.azure.com/microsoft/LiftedIXP/_git/DCPP build 20260823.1 On relative base path root Microsoft.FrameworkUdk , Microsoft.ProjectReunion.InteractiveExperiences.TransportPackage From Version 3.0.0-experimental-27300.1896.260713-1015.0 -> To Version 3.0.0-experimental-27300.1905.260822-1925.0 Microsoft.WindowsAppSDK.InteractiveExperiences From Version 3.0.0-experimental-Rolling.20260713.2 -> To Version 3.0.0-experimental-Rolling.20260823.1 --------- Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com> * [57514396] Use the central TSA area path in Foundation native builds * Fix "Cancel" button in the C# and C++ wapproj templates so that it returns to the "Configure your new project" menu instead of creating a broken project (#6708) * Add nuget cli alternative to Test-DotnetnNewTemplates for local execution * Add check in Build-VSIX-Local to verify that the templates are included in the VSIX * Add MsBuild parameter to build and install VSIX scripts * Set WindowsAppSDkVersion, WindowsSdkBuildToolsVersion,and WindowsSdkBuildToolsWinAppVersion to {name}$ (parent template parameter) instead of project template parameter * Move the Windows platform selection wizard from the Wapproj.vstemplate to the PackagedApp.vstemplate * Move the Windows platform selection wizard from the C++ Wapproj.vstemplate to the PackagedApp.vstemplate * Substitute publisher name from parent project in C++ wapproj Package.appxmanifest * Rename VsVersion in help guide to MsBuildVersion * Update missing MSBuild error message to include the MsBuildVersion selected in the script * Remove duplicate problems.Count newline * Remove extra excludedVersionPrefixes in Test-DotnetNewTemplates.ps1 * Add Reactor (Microsoft.UI.Reactor) dotnet new templates (#6620) * Add Reactor (Microsoft.UI.Reactor) dotnet new templates Adds four Reactor project templates to the Microsoft.WindowsAppSDK.WinUI.CSharp.Templates dotnet-new pack, mirroring the WinUI templates but for Microsoft.UI.Reactor (pure C#, no XAML): - Reactor Blank App (reactor, reactor-blank) - Reactor MVU App (reactor-mvu) - Reactor NavigationView (reactor-navview) - Reactor TabView App (reactor-tabview) Wired into dev/Templates/templates.props via the DotnetNewOnlyProjectTemplate slot (dotnet-new only, no VSIX, no manifest; Reactor apps run unpackaged). Each shares a common csproj referencing Microsoft.UI.Reactor + Microsoft.WindowsAppSDK, bundles the WinAppSDK runtime self-contained, and enables the Debug-only Reactor devtools surface. README and Test-DotnetNewTemplates.ps1 updated to document and validate the new templates. Validated end-to-end: pack -> install -> dotnet new -> build (Debug + Release) for all four templates. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> * Fix Reactor template runtime crash: remove TitleBar icon TitleBar(...).Icon(FontIcon(...)) threw System.ArgumentException (E_INVALIDARG) at runtime when Reactor set TitleBar.IconSource on Windows App SDK 2.1.3, so the scaffolded Blank, MVU, and TabView apps crashed on launch. The glyph was only a placeholder, so drop the icon; the title bar still shows the title text and all four templates now launch cleanly (validated with dotnet run). Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> * Bump Reactor templates to preview.12 and restore title-bar icon microsoft/microsoft-ui-reactor#855 fixes the IconResolver FontSize=NaN crash (FontIcon in an IconSource slot without an explicit size threw ArgumentException from TitleBar.set_IconSource). That fix ships in Microsoft.UI.Reactor 0.1.0-preview.12, so restore the placeholder title-bar app-mark icon in the Blank, MVU, and TabView templates and bump the default reactorVersion 0.1.0-preview.11 -> 0.1.0-preview.12 across all four templates. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> * Provision .NET 10 SDK in dotnet-new templates test stage The template smoke-test stage installed only .NET SDK 8.0.x, so scaffolding and building the Reactor templates failed with NETSDK1045 (Reactor targets net10.0 and declares a [10.0,) sdk-version constraint). The WinUI templates auto-detect their TFM from the active SDK, so they built net8.0 and passed, masking the gap. Add a second UseDotNet@2 step (param reactorDotnetSdkVersion, default 10.0.x) to the shared Test-Stage template so the agent has the .NET 10 SDK. Verified locally that the WinUI templates still build cleanly on the .NET 10 SDK, so existing coverage is unaffected. Both the official and PR pipelines consume this shared stage. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> * Address PR review: trim launchSettings comments, use per-template icons Review feedback from @DinahK-2SO on #6620: - Remove the explanatory comment block from the Reactor launchSettings.json files (the content overlapped the package README). - Give the MVU, NavigationView, and TabView templates their own icon.png (reusing the existing WinUI mvvm/navigation/tabview template icons) instead of all reusing the blank-app icon. The packaging/taskbar-icon, tabs-in-title-bar, and winui-* short-name comments are still open pending a check with the Reactor team. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> * Add winui-reactor* short-name aliases to Reactor templates Review feedback from @DinahK-2SO on #6620: give each Reactor template a winui-reactor* alias (winui-reactor, winui-reactor-mvu, winui-reactor-navview, winui-reactor-tabview) so they also surface under 'dotnet new list winui' alongside the other WinUI templates. README updated to note the aliases. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> * reactor-tabview: integrate tabs into the title bar Review feedback from @DinahK-2SO on #6620: instead of stacking a separate TitleBar row above the TabView, put the tabs up in the title bar (Edge/Terminal style) to look cleaner and save vertical space. Uses supported Reactor APIs: UseWindow().NativeWindow with ExtendsContentIntoTitleBar + SetTitleBar, the TabView TabStripHeader (app name at the leading edge) and TabStripFooter (draggable region), and UseDpi + UseWindowSize to reserve the caption-button inset (RightInset) across DPI and resize. Verified by scaffolding the template, building, running, and screenshotting the window: the tabs render inline in the title bar with the caption buttons clear. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> * Make Reactor templates packaged (MSIX) and match the WinUI templates Per review direction, the four Reactor templates now: 1. Are single-project MSIX packaged (like the WinUI templates) instead of unpackaged. Each gains app.manifest, Package.appxmanifest (EntryPoint Windows.FullTrustApplication since Reactor has no XAML App class), the shared Assets, and PublishProfiles. The csproj switches to EnableMsixTooling + Microsoft.Windows.SDK.BuildTools + Microsoft.Windows.SDK.BuildTools.WinApp so 'dotnet run' registers a loose package and launches with MSIX identity. templates.props sets RenameManifestFrom and the template.json files gain the publisher / guid / build-tools-version symbols and the \\$ modifier. 2. Visually match their WinUI counterparts: - reactor -> title bar (app icon) + empty content (blank canvas). - reactor-mvu -> centered 'Hello, WinUI!' + [+]/[-] icon counter (keeps the UseReducer MVU pattern under the same UI). - reactor-navview -> title bar + NavigationView Home/About + built-in Settings; pages render 'Title' + 'This is the X page'. - reactor-tabview -> MicaAlt, app-icon TabStripHeader, closable Home/About tabs with a '+' add button, tabs in the title bar. Validated end-to-end for all four: pack -> install -> scaffold -> build -> dotnet run (launches packaged with identity) -> screenshot matches the WinUI counterpart. README updated (templates are now packaged). Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> * reactor-mvu: greet 'Hello, Reactor!'; use WinUI type-ramp styles for font parity - MVU greeting is now 'Hello, Reactor!' (was 'Hello, WinUI!'). - Switch the Reactor text from Heading()/.SemiBold() (raw 28px Bold-700) to the type-ramp factories Title()/BodyStrong()/Body(), which apply the actual WinUI styles (TitleTextBlockStyle 28px Semibold-600, BodyStrongTextBlockStyle, BodyTextBlockStyle). This makes the Reactor headings/body render with the same weight and Segoe UI Variable optical size as the WinUI templates instead of a heavier bold. Applied to the mvu, navview, and tabview page text. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> * reactor-tabview: give tab pages a solid background to match WinUI The WinUI TabView template's pages set Background=SolidBackgroundFillColorTertiaryBrush, which covers the window's Mica in the tab content area. The Reactor version left the pages transparent, so MicaAlt showed through the content. Wrap the tab page content in a Border painted with that same tertiary brush so the content is a solid surface and only the tab strip / title bar show Mica, matching X_Tab. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> * reactor-tabview: stretch the tab page surface to fill the content area The solid tertiary page background only covered the text at the top because Reactor sizes the tab content to the element's desired size. Force the page Border to HorizontalAlignment/VerticalAlignment Stretch so the solid surface fills the whole tab content region, matching the WinUI TabView template (verified: the content is a uniform solid fill down to the window bottom). Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> * Fill reactor-tabview page surface to window height Match the WinUI TabView template's uniform tertiary content background by sizing the shared page surface to the window height, so it fills the whole tab content area instead of shrinking to its text (two-tone with Mica below). Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 16d7d2fc-3d7c-41e8-9999-0c2084ba9ea1 * Use Reactor's navigation system in reactor-navview Match the WinUI NavigationView template's shell: the title bar owns the back and pane toggle buttons, and NavigationView's own copies are hidden. Switch from hand-rolled tag state to Reactor's navigation handle (UseNavigation + NavigationHost), so the title bar back button is wired by .WithNavigation(nav) and tracks the back stack instead of never appearing. Also request the tall title bar layout the WinUI template uses. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 16d7d2fc-3d7c-41e8-9999-0c2084ba9ea1 * Toggle the nav pane on the control instead of mirrored state NavigationView opens and closes its pane on its own (light dismiss, display mode changes), so a separate IsPaneOpen state copy drifted out of sync and the title bar toggle needed two clicks to take effect. Flip IsPaneOpen on the control directly, the same way the WinUI template's code-behind does. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 16d7d2fc-3d7c-41e8-9999-0c2084ba9ea1 * Match the WinUI page transition in reactor-navview Reactor's NavigationHost slides pages in from the side, while WinUI's Frame defaults to an entrance transition that rises the new page up into place. Slide from the bottom so switching pages animates the same way. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 16d7d2fc-3d7c-41e8-9999-0c2084ba9ea1 * Trim the Reactor templates to match the XAML templates' style The Reactor templates carried long comments explaining Reactor concepts and how they differ from XAML, which made them read like documentation rather than a starting point. Keep only the brief, functional comments the XAML templates use, and a single pointer to the Reactor project info. Also drop the explicit navigation transition from reactor-navview: matching the XAML Frame's entrance animation added verbosity and called out a difference between the two, so use Reactor's default instead. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 16d7d2fc-3d7c-41e8-9999-0c2084ba9ea1 * Mark the Reactor templates as experimental Microsoft.UI.Reactor is prerelease and its API may still change, so label the templates accordingly: add `(Experimental)` to each template name, an `Experimental` classification so it shows in the dotnet new tags column, and a note in each description and in the README. Also correct the templates.props comment, which still described the Reactor apps as unpackaged with RenameManifestFrom unset; they are packaged (single-project MSIX) and do set it. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 16d7d2fc-3d7c-41e8-9999-0c2084ba9ea1 * Fix Reactor analyzer warnings in the MVU and TabView templates The templates tripped four of Reactor's analyzers, so a freshly scaffolded project did not build clean: - REACTOR_A11Y_001 (x2): the MVU counter's icon-only buttons had no accessible name. Add .AutomationName(). - REACTOR_A11Y_002: the TabView tab strip icon is decorative. Mark it .AccessibilityHidden(). - REACTOR_HOOKS_013: the initial tab array was reallocated on every render though only read on the first. Wrap it in UseMemo. - REACTOR_POOL_001: the page surface set MinHeight via .Set(...), which is reset when the element returns to the pool, so the tab content fill could be lost on re-render. Use the .MinHeight() modifier instead. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 16d7d2fc-3d7c-41e8-9999-0c2084ba9ea1 * Use $targetentrypoint$ in the Reactor manifests, like the XAML templates The Reactor manifests hardcoded EntryPoint=Windows.FullTrustApplication while every XAML template uses the $targetentrypoint$ token. The token already resolves to Windows.FullTrustApplication for these projects, so the generated AppxManifest.xml is unchanged - this just removes an unexplained difference between the two sets of templates. The four Reactor manifests are now byte-identical to their XAML counterparts. Verified: all four scaffold, build warning-free, generate the same EntryPoint=Windows.FullTrustApplication, and launch with package identity. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 16d7d2fc-3d7c-41e8-9999-0c2084ba9ea1 * Commit the Reactor templates' publish profiles The root .gitignore has a blanket `*.pubxml` rule, so the three publish profiles in each Reactor template were silently never added. They existed only on the authoring machine; a clean clone got none of them. The WinUI templates force-added theirs in #6407 for the same reason. Without the profiles the csproj's `<PublishProfile Condition="Exists(...)">` never resolves, so SelfContained is never set to true. Combined with PublishTrimmed=true for non-Debug configurations that fails a Release build outright: error NETSDK1102: Optimizing assemblies for size is not supported for the selected publish configuration. Please ensure that you are publishing a self-contained app. Force-add all 12 files so Release builds and publish work from a fresh clone, matching the WinUI templates. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 16d7d2fc-3d7c-41e8-9999-0c2084ba9ea1 * Stop .gitignore from swallowing template publish profiles The blanket `*.pubxml` rule silently ignored the Reactor templates' publish profiles, so they were never committed and Release builds failed from a clean clone (fixed in 8ea4586 by force-adding them). `git add -f` fixed those 12 files but not the mechanism: the next template added, or a new RID added to an existing one, hits the same trap and it is again invisible to anyone whose working tree still has the files on disk. Add a `!dev/Templates/**/*.pubxml` negation alongside the existing one for dev/vsix, so template publish profiles are committable by default. Publish profiles elsewhere in the repo stay ignored. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 16d7d2fc-3d7c-41e8-9999-0c2084ba9ea1 * Match the XAML templates' icon font and size The Reactor templates hardcoded `Segoe Fluent Icons` on their FontIcons and left the size at WinUI's default. The XAML templates do neither: they use `<FontIcon Glyph="..." />` with no FontFamily, inheriting SymbolThemeFontFamily, which resolves the right icon font for the OS — worth keeping given the templates support Windows 10 1809 and Segoe Fluent Icons is Windows 11 era. The MVVM template also sets FontSize="14" on its counter icons, which ours missed, so the buttons rendered larger than their XAML counterpart: XAML MVVM 58x41 Reactor MVU 67x51 -> 58x42 Verified against Microsoft.UI.Reactor 0.1.0-preview.12: both templates build warning-free and the glyphs render correctly (Icon(FontIcon(...)) resolves through IconResolver, not the Button(string) content path). Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 16d7d2fc-3d7c-41e8-9999-0c2084ba9ea1 * Update Reactor dotnet new templates for 0.1.0-preview.13 Reactor preview.13 adds declarative APIs that let the Navigation and TabView templates drop their imperative escape hatches: - NavigationView: use IsBackButtonVisible / IsPaneToggleButtonVisible and .IsPaneOpen(value, handler) instead of UseRef + OnMount downcast, and select the built-in Settings item via NavigationViewElement.SettingsTag. OnSelectedTagChanged still reports null for Settings by design, so TagToRoute keeps handling both SettingsTag and null. - TitleBar: use .Tall() instead of the UseEffect + DispatcherQueue hop and the redundant .Height(48). - TabView: set FillContentArea, removing the MinHeight workaround. Also bump the reactorVersion default to 0.1.0-preview.13 in all four Reactor template.json files. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 38f0823a-2ee4-4c65-8f3f-7dde6a049509 * Let the OS size the window, like the XAML templates Drop the hardcoded 1000x700 from all four Reactor templates. Reactor PR #924 makes ReactorApp.Run's width/height optional, so omitting them lets the OS pick the size, matching the XAML templates which set no size at all. Verified identical to a freshly scaffolded XAML app. This requires 0.1.0-preview.13; before #924, omitting width/height meant a hardcoded 1024x768 rather than an OS-chosen size. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 38f0823a-2ee4-4c65-8f3f-7dde6a049509 * Add the MsixPackage launch profile to the Reactor templates The Reactor templates were originally unpackaged and their launchSettings.json only declared `commandName: Project` profiles. Making them single-project MSIX updated the csproj and added Package.appxmanifest but left launchSettings behind, so F5 from Visual Studio failed: ...launchSettings.json does not contain a profile with commandName 'MsixPackage'. To debug a packaged single-project MSIX solution, a profile with command name MsixPackage in launchSettings.json is required. `dotnet run` goes through Microsoft.Windows.SDK.BuildTools.WinApp instead, so it worked throughout and the gap went unnoticed. Declare the same Package / Unpackaged pair the WinUI XAML templates ship, with Package first so it is the F5 default, and keep the Reactor devtools profile alongside them. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 16d7d2fc-3d7c-41e8-9999-0c2084ba9ea1 * Float the Windows App SDK version in the Reactor templates The Reactor templates pinned Microsoft.WindowsAppSDK to 2.1.3 while the WinUI XAML templates default to `*`. That pinned new projects to an older SDK than the one Visual Studio offers everywhere else — 2.3.1 is current, so scaffolded Reactor apps were two releases behind for no reason. 2.1.3 was the version Reactor happened to be built against, not a hard floor: Microsoft.UI.Reactor 0.1.0-preview.13 depends on Microsoft.WindowsAppSDK.WinUI >= 2.1.0. Keep the requirement in the parameter description rather than encoding it as the pin, matching the WinUI templates. Verified with the floated default: all four templates resolve Microsoft.WindowsAppSDK 2.3.1, build warning-free, and launch with package identity. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 16d7d2fc-3d7c-41e8-9999-0c2084ba9ea1 * Accept MSB4181 for the invalid-version restore test on .NET SDK 10 The dotnet-new template test stage previously installed only the .NET 8 SDK. Adding the .NET 10 SDK (needed because the Reactor templates target net10.0) means the muxer now selects 10.0.400 for the pre-existing winui negative tests as well, which changes the diagnostic NuGet emits for an unparseable package version: SDK 8.0.424 / 9.0.317 : no error code; "'not-a-version' is not a valid version string." SDK 10.0.400 : MSB4181 - RestoreTask returns false without logging the descriptive error, so no NU code surfaces at all. The old assertion short-circuited on any error code being present and demanded NU1105, so MSB4181 failed the run. (NU1105 never actually surfaced on any tested SDK; the test passed via the descriptive-message fallback.) Accept NU1105/MSB4181 or the descriptive message, and stop a code's presence from bypassing the fallback. Verified on 8.0.424 / 9.0.317 / 10.0.400. Unrelated failures (NU1101, NU1301) still fail the assertion, so it is not weakened to "any failure". Scenario 5's build check (NETSDK1004), scenario 6 (NU1102) and scenario 7 (NU1301) were confirmed unchanged on SDK 10. Also corrects an adjacent comment that said NETSDK1005 where the check and the observed behaviour are both NETSDK1004. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 16d7d2fc-3d7c-41e8-9999-0c2084ba9ea1 * Pin the Reactor test-stage .NET SDK instead of floating 10.0.x Every other UseDotNet@2 task in this repo pins an exact SDK (6.0.414, 6.0.427, 8.0.100, 9.0.200, 10.0.111); #6624 added the BuildVSIX pin so Component Governance scans a patched toolchain, and #6699 bumped it deliberately for a security release. reactorDotnetSdkVersion was the only new floating pin. Floating is what broke CI: '10.0.x' resolved to 10.0.302 when the task was added on 2026-07-23, then silently jumped a whole feature band when 10.0.400 shipped on 2026-08-11. 10.0.400 changed the NuGet diagnostic for an unparseable package version, so the pre-existing winui invalid-version smoke test started failing with no corresponding source change. Pinned to 10.0.400 rather than the 10.0.111 used by BuildVSIX. The Reactor templates cannot use the 1xx servicing band: Microsoft.UI.Reactor's analyzers and source generators (Reactor.Analyzers, Reactor.Wrappers.Generator, Reactor.Localization.Generator) reference Roslyn 5.6.0.0, and 10.0.111 ships Roslyn 5.0.0.0, so all three are silently disabled with CS9057 while the build still reports success. Verified by building the same scaffolded project on both SDKs: 10.0.111 -> 3x CS9057, 10.0.400 (Roslyn 5.9.0.0) -> 0 warnings. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 16d7d2fc-3d7c-41e8-9999-0c2084ba9ea1 * Accept NETSDK1005 for the invalid-version build test on .NET SDK 10 Follow-up to 5ff625e, which fixed the restore assertion in the same scenario. The build assertion immediately after it failed for the same underlying reason. On .NET SDK 10 NuGet's RestoreTask fails (MSB4181) but still writes a partial obj/project.assets.json. The subsequent --no-restore build therefore reports NETSDK1005 (assets file has no target for the project's TFM) rather than NETSDK1004 (assets file missing). Accept either, since both mean restore did not produce usable assets. Scenario 7's list gains NETSDK1005 for the same reason; it currently resolves to NU1301, but NETSDK1004 is in that list for the 'restore never succeeded' case whose SDK 10 equivalent is 1005. This also reverts the NETSDK1005 -> NETSDK1004 comment change from 5ff625e. That comment was correct as written; I changed it based on a repro that used a bare net8.0 project with no obj directory, which produces NETSDK1004 and does not reproduce the real template's behaviour. Re-verified with a faithful repro (net10.0-windows10.0.26100.0, WinUI props, same build flags), which reproduces CI exactly: assets file present after the failed restore, build fails with NETSDK1005. All four error-code assertions in this script are now backed by faithful repros on the pinned SDK 10.0.400: restore MSB4181, build NETSDK1005, scenario 6 NU1102, scenario 7 NU1301. Unrelated failures still throw. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 16d7d2fc-3d7c-41e8-9999-0c2084ba9ea1 --------- Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 16d7d2fc-3d7c-41e8-9999-0c2084ba9ea1 Copilot-Session: 38f0823a-2ee4-4c65-8f3f-7dde6a049509 * dotnet new WinUI3 templates 0.0.7-alpha (#6729) * Propagate the PackageReference version into the C# wapproj template's BlankApp project file (#6705) * Fix AppInstance process handle validation (#6733) * Fix AppInstance process handle validation Open non-current processes with SYNCHRONIZE once and transfer the validated handle into AppInstance before registering the termination wait. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Potential fix for pull request finding Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> * Set ApplicationIcon in the C# app templates (#6728) * Set ApplicationIcon in the C# app templates The eight C# app templates ship Assets\AppIcon.ico and reference it from the window (AppWindow.SetIcon in the XAML templates, TitleBar.Icon in the Reactor ones), but none of them set <ApplicationIcon>, so the icon was never embedded into the built executable as a Win32 icon resource. Explorer, shortcuts, and the taskbar for an unpackaged build therefore showed the default .NET icon. Guarded with Condition=Exists so the property is simply skipped if a project does not have the asset, matching the existing PublishProfile pattern in these same templates. Applied to all eight app templates that ship the asset -- the four WinUI XAML ones and the four Reactor ones -- rather than only the Reactor set, so the templates stay consistent with each other. ClassLibrary, PackagedApp, and UnitTestApp do not ship an AppIcon.ico and are untouched. Only ProjectTemplate.csproj is modified: that is the file scaffolded for the user by both dotnet new and the VSIX. The WinUI.Desktop.Cs.*.csproj files are VSSDK packaging projects for the VSIX itself, not scaffolded output. Validated by scaffolding and building all eight templates (Debug, x64): all build clean and the icon is embedded in the produced exe, confirmed by ExtractAssociatedIcon returning a 32x32 icon for each. The two warnings from winui-mvvm are pre-existing MVVMTK0045 diagnostics from the MVVM Toolkit and are unrelated. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 16d7d2fc-3d7c-41e8-9999-0c2084ba9ea1 * Bump Reactor to 0.1.0-preview.14 and drop the explicit title bar icon Reactor 0.1.0-preview.14 makes TitleBar(...) inherit the window's icon (microsoft/microsoft-ui-reactor#1153), so the explicit .Icon("ms-appx:///Assets/AppIcon.ico") in the templates is now redundant. Removing it keeps the scaffolded App.cs to the shape a starter template should have, and the title bar still renders the app mark. Applies to the three templates that use a TitleBar element: ReactorBlankApp, ReactorMvuApp and ReactorNavigationApp. ReactorTabViewApp has no TitleBar -- it extends content into the title bar with a custom drag region and renders its icon through TabStripHeader = Image(...), which is a different surface that the inherit behaviour does not cover -- so it keeps its explicit reference and is intentionally untouched. Validated against the real 0.1.0-preview.14 package, four scaffolded apps, with the icon line present and absent: control, .Icon present, preview.14 title bar mark shown line removed, preview.14 title bar mark shown <- the change line removed + icon: arg, preview.14 title bar mark shown line removed, preview.13 NO mark The last row is the negative control: identical source and capture method, only the package version differs, so the mark on preview.14 is caused by the inherit behaviour rather than by something incidental. All four templates were then scaffolded from the built pack and built clean on x64: Debug 0 warnings, Release 2 warnings. The Release warnings are pre-existing IL2104 trim warnings from Microsoft.Windows.SDK.NET and WinRT.Runtime, unrelated to this change and present without it. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 16d7d2fc-3d7c-41e8-9999-0c2084ba9ea1 --------- Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 16d7d2fc-3d7c-41e8-9999-0c2084ba9ea1 * Fix errors from missing resource dll with version info (#6725) * [57514396] Use central TSA config for Foundation source analysis (#6738) * Normalize line endings in AppInstance.cpp (#6752) * AppNotificationManager::Show and AppInstance::GetInstances: refactor to noexcept workers (Bug 61688595) (#6714) Refactor two hot-path WinRT projection entry points so a failed HRESULT does not trigger the deep C++/WinRT projection rethrow path that exhausted the stack via WIL's FormatMessage-based exception logging chain inside ResultFromCaughtException_CppWinRt::catch$8 (the Watson failure signature for this crash bucket). AppNotificationManager::Show: move the throwing body into a private noexcept HRESULT worker (ShowImpl) using RETURN_HR_IF / RETURN_IF_FAILED / CATCH_RETURN. The public Show keeps the IsSupported() early-return and rethrows any failure HRESULT via THROW_IF_FAILED(ShowImpl(...)). AppLifecycle::AppInstance::GetInstances: same pattern. The body becomes GetInstancesImpl(IVector<AppInstance>& out) noexcept; the public GetInstances() is a thin THROW_IF_FAILED(GetInstancesImpl(...)) wrapper. Internal callers (RedirectActivationToAsync at line 636) are unaffected because the public signature is unchanged. These are the two entry points observed in the Watson cabs attached to this bucket: WinUI3 Controls Gallery cabs originate in Show, and the auto-filer cab originates in Photos -> AppInstance::GetInstances (frames 16-22 in the cab call stack). The catch handler one frame deeper is mis-attributed by Watson's PDB walker to SecurityDescriptorHelpers::NonDelegatingGetTrustLevel::catch$0 (lexically-nearest catch symbol). AB#61688595 Co-authored-by: James Pike <jamespik@microsoft.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Retire the standalone StoragePickersTestApp (#6779) Remove the specialized UI harness, its assets, and solution mappings to simplify ongoing build maintenance. Keep the Storage Pickers implementation and automated tests unchanged. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Change WindowsAppSDK-DotnetNewTemplates template from Microsoft.NonOfficial to Microsoft.Official template (#6783) * Add OneBranch.Official.CrossPlat.yml template to WindowsAppSDK-DotnetNewTemplates.yml * Use Microsoft Official template for dotnet templates Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 30bef3b6-3b91-4f20-96cd-7c242a8a370f --------- Copilot-Session: 30bef3b6-3b91-4f20-96cd-7c242a8a370f * Add network isolation to WindowsAppSDK-DotnetNewTemplates.yml (#6787) * Use path filter for template PR validation (#6782) * Skip OneBranch tool download when running template change validation on PRs from forks * Use ADO path filter for template PR validation Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 6baeec26-f59b-466a-8eab-cd3b09b19380 --------- Copilot-Session: 6baeec26-f59b-466a-8eab-cd3b09b19380 * Reactor templates: bump to 0.1.0-preview.16 and raise WindowsAppSDK floor to 2.2.0 (#6786) Updates the four Reactor dotnet-new templates for the 0.1.0-preview.16 release: reactorVersion 0.1.0-preview.14 -> 0.1.0-preview.16 windowsAppSdkVersion documented floor 2.1.3 -> 2.2.0 microsoft/microsoft-ui-reactor#1259 adopts ApplicationData.GetForUnpackaged(), a Windows App SDK 2.2.0 API, and raises Microsoft.UI.Reactor's dependency on Microsoft.WindowsAppSDK.WinUI to 2.2.1. Verified that commit is contained in the v0.1.0-preview.16 tag, and that Directory.Build.props at that tag declares WindowsAppSDKVersion 2.2.0 / WindowsAppSDKWinUIVersion 2.2.1. These templates reference the full Microsoft.WindowsAppSDK metapackage (not the lean WinUI sub-package) and scaffold packaged single-project MSIX apps, so the correct consumer floor is metapackage 2.2.0 - the first version whose WinUI dependency is 2.2.1 (2.1.3 -> WinUI 2.1.0; 2.2.0 -> WinUI 2.2.1). Both edits ship together because the mismatch they prevent is silent, not a restore error. Measured with a stub package carrying the post-#1259 dependency shape: pinning --wasdk-version 2.1.3 restores with exit code 0 and zero warnings, resolving Microsoft.WindowsAppSDK.WinUI 2.2.1 while the metapackage holds Microsoft.WindowsAppSDK.Runtime at exactly [2.1.3]. WinUI is only ever a transitive reference, so NuGet takes the highest floor and never reports NU1605; the result is 2.2.1 reference assemblies over a 2.1.3 runtime, which builds clean and fails at runtime. The same probe at 2.2.0 resolves Runtime 2.2.0. Since the toolchain raises no error, the description text is the only guardrail a user pinning explicitly will ever see. Validated by scaffolding all four templates from a locally packed template pack: each emits Microsoft.UI.Reactor and Microsoft.UI.Reactor.Devtools at 0.1.0-preview.16, Microsoft.WindowsAppSDK at the default '*', and a Package.appxmanifest. Also verified the explicit pin path (--wasdk-version 2.2.0 --reactor-version 0.1.0-preview.16). Restore/build validation is deferred to CI: 0.1.0-preview.16 is on nuget.org but has not yet mirrored to the internal package proxy reachable from this machine. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> * Pin GitHub Actions to full-length commit SHAs (#6791) Co-authored-by: Dan Fiedler <danfiedler@microsoft.com> * Retry transient bootstrap initialization registration failures in tests (#6816) * Retry transient bootstrap initialization failure Retry MddBootstrapInitialize only when DDLM registration is temporarily unavailable, using a bounded exponential backoff. AB#62489699 * Migrate TouchDownBuild-WinAppSDK (#6814) * Fix TouchDown variable group Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: e6b7e13d-59ce-4751-91f4-e8e589787837 * Fix TouchDown service connection Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: e6b7e13d-59ce-4751-91f4-e8e589787837 * Use TouchDown Azure resource connection Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: e6b7e13d-59ce-4751-91f4-e8e589787837 --------- Copilot-Session: e6b7e13d-59ce-4751-91f4-e8e589787837 --------- Co-authored-by: Roman Sivak (AKVELON INC) <v-romansivak@microsoft.com> Co-authored-by: ssparach <128866445+ssparach@users.noreply.github.com> Copilot-Session: e6b7e13d-59ce-4751-91f4-e8e589787837 --------- Co-authored-by: Lauren Ciha <laurenciha@microsoft.com> Co-authored-by: Gordon Lam <73506701+yeelam-gordon@users.noreply.github.com> Co-authored-by: Howard Kapustein <howardk@microsoft.com> Co-authored-by: Vineeth Thomas Alex <vineeththomasalex@gmail.com> Co-authored-by: Vineeth Thomas Alex <vithoma@microsoft.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: dotnet-maestro[bot] <42748379+dotnet-maestro[bot]@users.noreply.github.com> Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com> Co-authored-by: v-goradojcic <v-goradojcic@microsoft.com> Co-authored-by: Alexandre Zollinger Chohfi <alzollin@microsoft.com> Co-authored-by: Dinah Xiaoman G <116714259+DinahK-2SO@users.noreply.github.com> Co-authored-by: Scott Jones <sjones@microsoft.com> Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> Co-authored-by: Manodasan Wignarajah <mawign@microsoft.com> Co-authored-by: Dreynor87 <wall_c.s@outlook.com> Co-authored-by: James Pike <jamespik@microsoft.com> Co-authored-by: Dan Fiedler <danfiedler@microsoft.com> Co-authored-by: romsi1983 <41230962+romsi1983@users.noreply.github.com> Co-authored-by: Roman Sivak (AKVELON INC) <v-romansivak@microsoft.com> Co-authored-by: ssparach <128866445+ssparach@users.noreply.github.com> Copilot-Session: 2b34993b-0dcf-4789-94c5-97fd92cce84d Copilot-Session: 5474160f-e555-4254-899b-783ad9211b71 Copilot-Session: 484c9277-ea15-4f85-a4a0-0429347ade48 Copilot-Session: 16d7d2fc-3d7c-41e8-9999-0c2084ba9ea1 Copilot-Session: 38f0823a-2ee4-4c65-8f3f-7dde6a049509 Copilot-Session: 30bef3b6-3b91-4f20-96cd-7c242a8a370f Copilot-Session: 6baeec26-f59b-466a-8eab-cd3b09b19380 Copilot-Session: e6b7e13d-59ce-4751-91f4-e8e589787837
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.
The runtime package is what contains
Microsoft.WindowsAppRuntime.Insights.Resource.dllas that is where we can say this runtime framework package is this version. But when someone uses individual component packages without the runtime package, that currently leads to errors due to the DLL is not there. Instead of erroring, we should safely handle these situations based on what info we can provide.Version info, we just return 0 or empty now when the dll is missing as we can't say what version it is given each component package can be a different version and there is no framework package involved.IsSelfContainedcheck that seems to also call this, that now returns true to indicate it is self-contained when this DLL isn't there.Fixes #6387
Fixes #6071
A microsoft employee must use /azp run to validate using the pipelines below.
WARNING:
Comments made by azure-pipelines bot maybe inaccurate.
Please see pipeline link to verify that the build is being ran.
For status checks on the main branch, please use TransportPackage-Foundation-PR
(https://microsoft.visualstudio.com/ProjectReunion/_build?definitionId=81063&_a=summary)
and run the build against your PR branch with the default parameters.