FI: main -> release/dev/monobuild (2026-07-23)#6650
Draft
kythant wants to merge 23 commits into
Draft
Conversation
… making downloading-latest-package opt-in (#6555) * Fix Foundation PR builds: make latest-nightly VSIX download opt-in * Disambiguate by-branch nightly download step name
**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. **Commits:** * Restore keyboard focus after Storage Pickers dialog closes (#6505) The COM file dialog runs on a background thread, so SetFocus on close is ignored. Capture the focused window on the UI thread and marshal SetFocus back via the DispatcherQueue. Adds DialogFocusRestorer, applied to all five pick entry points. * add a manual test case
…ures (#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>
…ngs() (#6558) * Fix bad regkey path for ApplicationData.GetForUnpackaged().LocalSettings() * Fixed Clear*() * Removed obsolete references to Roaming* * Fixed tests to use consistent test data --------- Co-authored-by: Scott Jones <sjones@microsoft.com>
…port all versions of .NET 8.0 (#6565) * Add mvvm templates to Test-DotnetNewTemplates.ps1 * Add a -DotnetSdkVersion parameter to mimic CI build locally * Use C# 12 (.NET 8) field syntax for greeting and counter in MVVM template for .NET 8 compatibility
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>
…on/_git/WindowsAppSDKAggregator build 2.0.6-dev.experimental2 (#6542) On relative base path root Microsoft.WindowsAppSDK.Base From Version 2.0.6-dev.experimental1 -> To Version 2.0.6-dev.experimental2 Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com> Co-authored-by: v-arlysenko <v-arlysenko+github@microsoft.com> Co-authored-by: agniuks <41223743+agniuks@users.noreply.github.com>
…templates (#6523) * Set PackageReferences to use * by default * Replace Version="*" with template tokens in shared .csproj files Replace hardcoded Version="*" PackageReferences with *$ template tokens in all 6 shared .csproj files. These tokens are resolved by the dotnet new template engine (via template.json symbols) and by the VSIX template engine (via CustomParameter entries). Add defensive CustomParameter entries with Value="*" to each .vstemplate file so that VSIX templates resolve the new tokens to latest-version semantics, matching the dotnet new default behavior. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Add version pinning parameters to dotnet new template configs Replace the UseLatestWindowsAppSDK boolean and hardcoded version defaults with freeform text parameters (defaultValue="*") that let users pin specific NuGet package versions at scaffold time via --wasdk-version, --build-tools-version, etc. Remove all B17581D1 'update to latest' post-actions since floating Version="*" already resolves to the latest stable release via NuGet. The 210D431B restore post-action is retained. Add version parameters to the class-library template which previously had none. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Expose version parameters in ide.host.json for IDE integration Replace the UseLatestWindowsAppSDK IDE entry with version parameter entries so that IDEs like Visual Studio and Rider surface the new version pinning options in their template dialogs. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Add CLI aliases for version parameters in dotnetcli.host.json Register long and short CLI aliases for each version parameter: --wasdk-version / -wasdkv --build-tools-version / -btv --winapp-version / -wav --mvvm-toolkit-version / -mtv (mvvm-app only) --mstest-version / -mv (unit-test only) --test-sdk-version / -tsv (unit-test only) Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Extend template test script with version parameter scenarios Add winui-tabview and winui-mvvm to the template test matrix. Add Assert-CsprojPackageVersion helper function and 6 test scenarios: 1. Default (no version) produces Version="*" 2. Single pinned version (--wasdk-version) 3. All versions pinned 4. Pre-release version string (e.g. 1.8.0-preview1) 5. Invalid version: scaffold succeeds, build fails 6. Nonexistent version (99.99.99): scaffold succeeds, build fails Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Fix PackageReference lookup in test script to use XPath Dot-navigation on multiple ItemGroup elements fails when some lack PackageReference children. Use SelectNodes XPath query instead. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Hide version fields behind 'Use latest project dependencies' checkbox Add useLatestDependencies bool parameter (default: true) to all 6 template.json configs. In ide.host.json, version fields use isVisible='!useLatestDependencies' so they only appear when the checkbox is unchecked. CLI behavior is unchanged. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Revert "Hide version fields behind 'Use latest project dependencies' checkbox" This reverts commit 54ca3e7. * Update IDE version labels from 'empty = latest' to '* = latest' Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Reset custom parameter names from Resolved{Dependency}Version to {DependencyVersion * Update OptionalVSIXVersion to 2.0.27 * Update default to 2.0.27 * Reset default OptionalVSIXVersion to default with instructions for overriding the value in the pipelines * Update nonexistent version test to include check for NU1102 ('Unable to find package {packageName} wtih version {version}) * Update invalid version test for package restore to include the proper error codes: NU1105 on restore, NETSDK1005 on build * Add pass condition to invalid version string case when no error code is included in the message * Correct error check from NETSDK1005 to NETSDK1004 * Add a test for an offline and recovery scenario --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
The MCP helper reused GITHUB_TOKEN as a bearer token when downloading image and ZIP URLs extracted from untrusted issue/PR Markdown, leaking the token to any attacker-controlled host referenced in issue content. Centralize auth in auth.js: attach the token only to an explicit allowlist of GitHub API hosts (api.github.com) over HTTPS. Image and ZIP downloads from arbitrary hosts are now fetched without Authorization. Adds a regression test proving arbitrary hosts never receive the token while api.github.com does. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…6588) Adds **WindowsAppSDK-Templates-PR** pipeline to "/azp run" with path gate so it can verify GitHub PRs that touch `dev/Templates/**` without blocking unrelated PRs. Details: - Make the WindowsAppSDK-Templates-PR pipeline to be triggered by "/azp run" comments, for github PRs targeting main branch (set in policy, not in this code) - when the `WindowsAppSDK-Templates-PR` pipeline launched, it checks with git diff to see if the current PR changes anything under folder `dev/Templates`. - If not, `WindowsAppSDK-Templates-PR` will be passed, and silently skip templates check. - if the templates folder is touched, run build verifications and smoke tests for all the templates. - By default `WindowsAppSDK-Templates-PR` runs with the latest stable version of WindowsAppSDK. Adding a variable (by default = "*") to customize the WindowsAppSDK version on pipeline's launching page, so users can run tests for their target packages (if they want to).
* specs: Add EnergySaverStatus2 API spec Introduces spec for the new Microsoft.Windows.System.Power.PowerManager EnergySaverStatus2 API, which expands the legacy two-state EnergySaverStatus (On/Off) to a three-state model (Off/Standard/HighSavings) reflecting the Windows Germanium Energy Saver update. New APIs documented: - PowerManager.EnergySaverStatus2 property - PowerManager.EnergySaverStatus2Changed event - PowerManager.IsEnergySaverStatus2Supported() method - EnergySaverStatus2 enum ADO: Task 60383995, 61020635, 61020638, 61020649 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Revise EnergySaverStatus2 API documentation Updated EnergySaverStatus2 documentation to reflect changes in API behavior and requirements for Windows 11, 24H2. Clarified enum descriptions and fixed formatting issues. * Add namespace for PowerNotificationsContract Added namespace declaration for PowerNotificationsContract. * Implement feedback Updated documentation to reflect changes in the Energy Saver feature, including the introduction of three modes: Off, Standard, and High Savings. Removed outdated examples and remarks related to unsupported OS builds. * specs: add deprecation notices for legacy EnergySaverStatus API Mark PowerManager.EnergySaverStatus, PowerManager.EnergySaverStatusChanged, and the EnergySaverStatus enum as deprecated in the EnergySaverStatus2 spec. Deprecation notices added in Background section, EnergySaverStatus2 enum Remarks, and Appendix/Legacy API compatibility section. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Update deprecation notice for EnergySaverStatus Clarify the limitation of the legacy EnergySaverStatus and its impact on app behavior. * Remove non-contractual battery level * Rewrite wording to avoid confusion * update default or unknown state * fix alignment * replace disabled with inactive * replace disabled with inactive * Update EnergySaverStatus2.md to remove extending remarks Removed remarks about extending EnergySaverStatus2 and handling unknown enum values. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…#6545) Adds StoragePickersTestApp, a WinUI 3 C++ app that exercises the new Microsoft.Windows.Storage.Pickers APIs next to the legacy UWP pickers, so the two can be compared with a real user experience. It builds on WinAppSDK 1.6 (the last release with WinUI but without the new Pickers API), whose Microsoft.UI.Xaml requires WebView2 >= 1.0.2651.64. This bumps the WebView2 toolset dependency from the stale 1.0.961.33, a build/test-only package present in no product binary, and registers the app in the solution. ABForward is realigned to the same version. Backgroud: A similar test app was added in #6195 before, but it's dependent package versions conflicts with the repo config, so it was removed in #6287. This PR adds the test app and updates the version numbers.
* Remove the NuGetPackageInstaller WizardExtension from each C# .vstemplate file * Remove the $ parameter from the C# .vstemplate files * Remove the wizard includes from the C# template VSIX .csproj * Remove the check for the NuPackToolsVsix extension
…(supersedes #5828) (#6603) * Add fallback for MrmGetFilePathFromName * Update dev/MRTCore/mrt/Core/src/MRM.cpp Co-authored-by: Rafael Rivera <rafael@withinwindows.com> * Complete MrmGetFilePathFromName fallback: return S_OK with a valid path PR #5828 added a DefaultFallback search pass to restore the documented "always succeed, return a best-effort path" contract of MrmGetFilePathFromName (regressed in #4965 to return ERROR_FILE_NOT_FOUND, breaking ResourceManager creation when no resources.pri exists - #5814 / #5940). However DefaultFallback was unreachable: both terminal passes (ParentPathForFileName, exeDirForModulePri) jumped to Final, skipping it. The function therefore returned S_OK with *filePath == nullptr, which crashes callers that dereference the path (e.g. MrmCreateResourceManager rejects an empty path with E_INVALIDARG, and the GetFilePath unit test AVs on wcsstr). Changes: - MRM.cpp: route both terminal passes into DefaultFallback so it runs as the final pass; return 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 - matching pre-#4965 (legacy) behavior. Preserve the module directory since the parent-folder search mutates exeDir in place. - Helper.cpp (GetDefaultPriFile): the sparse-packaged [modulename].pri fallback gated on IsResourceNotFound(hr); since MrmGetFilePathFromName now returns S_OK, gate on actual file existence (CheckFile) instead, and only adopt the unpackaged result if it resolves to an existing file (avoids re-regressing #6376 / microsoft-ui-xaml#10856). - 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 again (they were bypassed in #5498 / #5919 after the #4965 regression, which is why the regression shipped undetected). Verified locally (x64 Debug): MrmUnitTest 21/21, MrtCoreUnpackagedTests 27/27. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --------- Co-authored-by: 王宇逸 <Strawberry_Str@hotmail.com> Co-authored-by: Rafael Rivera <rafael@withinwindows.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…sses (#5987) (#6619) The Windows App SDK auto-initializer sets the process environment variable MICROSOFT_WINDOWSAPPRUNTIME_BASE_DIRECTORY (a requirement for PublishSingleFile SxS manifest redirection). Because it is a process environment variable, it is inherited by child processes spawned via CreateProcess: a child's MRTCore then resolved the parent's resources.pri, and reg-free WinRT redirection could be steered by a parent-controlled directory. Stamp the owning process id in MICROSOFT_WINDOWSAPPRUNTIME_BASE_DIRECTORY_PID and honor the base directory only when the stamp matches the current process: - MRM.cpp and catalog.cpp ignore the base directory unless it was stamped by the current process, so inherited (foreign) values fall back to the module directory. A parent cannot forge a stamp equal to the not-yet-known child pid, so this also prevents steering where an elevated child reads data files from. - Move the base-directory setter out of the URFW auto-initializer into a new, clearly-named WindowsAppRuntimeBaseDirectoryAutoInitializer; the URFW file is now runtime-load only. This addresses the filename confusion raised on the issue. Add MrtCore EnvironmentVariableIsolationTests: an in-process PID-guard test and a real cross-process test proving a spawned child ignores the inherited base directory. Copilot-Session: dac4165f-ec13-4406-9206-60cd55b24c2b Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Install the secure .NET 10 servicing SDK before the VSIX restore and build steps so Component Governance scans the patched toolchain.
…ation with global:: (#6633) The generated WindowsAppRuntimeBaseDirectoryAutoInitializer.cs lives in namespace Microsoft.Windows.ApplicationModel.WindowsAppRuntime.BaseDirectoryCS. When compiled into a consumer that references the Microsoft.Windows.System WinMD, the leading 'System' in 'System.Globalization.CultureInfo' binds to Microsoft.Windows.System (via the enclosing Microsoft.Windows namespace) instead of the root System namespace, producing CS0234 (namespace 'Globalization' does not exist in 'Microsoft.Windows.System'). This broke TransportPackage-Foundation-Nightly. Qualify with global:: to force the root namespace.
* Update dependencies from https://dev.azure.com/microsoft/LiftedIXP/_git/DCPP build 20260602.2 On relative base path root Microsoft.FrameworkUdk , Microsoft.ProjectReunion.InteractiveExperiences.TransportPackage From Version 3.0.0-experimental-27300.1878.260525-0800.0 -> To Version 3.0.0-experimental-27300.1880.260601-1300.2 Microsoft.WindowsAppSDK.InteractiveExperiences From Version 3.0.0-experimental-Rolling.20260525.1 -> To Version 3.0.0-experimental-Rolling.20260602.2 * Update dependencies from https://dev.azure.com/microsoft/LiftedIXP/_git/DCPP build 20260602.5 On relative base path root Microsoft.FrameworkUdk , Microsoft.ProjectReunion.InteractiveExperiences.TransportPackage From Version 3.0.0-experimental-27300.1878.260525-0800.0 -> To Version 3.0.0-experimental-27300.1881.260602-1050.0 Microsoft.WindowsAppSDK.InteractiveExperiences From Version 3.0.0-experimental-Rolling.20260525.1 -> To Version 3.0.0-experimental-Rolling.20260602.5 * Update dependencies from https://dev.azure.com/microsoft/LiftedIXP/_git/DCPP build 20260606.1 On relative base path root Microsoft.FrameworkUdk , Microsoft.ProjectReunion.InteractiveExperiences.TransportPackage From Version 3.0.0-experimental-27300.1878.260525-0800.0 -> To Version 3.0.0-experimental-27300.1882.260605-1010.1 Microsoft.WindowsAppSDK.InteractiveExperiences From Version 3.0.0-experimental-Rolling.20260525.1 -> To Version 3.0.0-experimental-Rolling.20260606.1 * Update dependencies from https://dev.azure.com/microsoft/LiftedIXP/_git/DCPP build 20260608.3 On relative base path root Microsoft.FrameworkUdk , Microsoft.ProjectReunion.InteractiveExperiences.TransportPackage From Version 3.0.0-experimental-27300.1878.260525-0800.0 -> To Version 3.0.0-experimental-27300.1883.260608-1315.0 Microsoft.WindowsAppSDK.InteractiveExperiences From Version 3.0.0-experimental-Rolling.20260525.1 -> To Version 3.0.0-experimental-Rolling.20260608.3 * Update dependencies from https://dev.azure.com/microsoft/LiftedIXP/_git/DCPP build 20260609.3 On relative base path root Microsoft.FrameworkUdk , Microsoft.ProjectReunion.InteractiveExperiences.TransportPackage From Version 3.0.0-experimental-27300.1878.260525-0800.0 -> To Version 3.0.0-experimental-27300.1884.260609-0730.0 Microsoft.WindowsAppSDK.InteractiveExperiences From Version 3.0.0-experimental-Rolling.20260525.1 -> To Version 3.0.0-experimental-Rolling.20260609.3 * Update dependencies from https://dev.azure.com/microsoft/LiftedIXP/_git/DCPP build 20260612.1 On relative base path root Microsoft.FrameworkUdk , Microsoft.ProjectReunion.InteractiveExperiences.TransportPackage From Version 3.0.0-experimental-27300.1878.260525-0800.0 -> To Version 3.0.0-experimental-27300.1885.260612-1130.0 Microsoft.WindowsAppSDK.InteractiveExperiences From Version 3.0.0-experimental-Rolling.20260525.1 -> To Version 3.0.0-experimental-Rolling.20260612.1 * Update dependencies from https://dev.azure.com/microsoft/LiftedIXP/_git/DCPP build 20260616.3 On relative base path root Microsoft.FrameworkUdk , Microsoft.ProjectReunion.InteractiveExperiences.TransportPackage From Version 3.0.0-experimental-27300.1878.260525-0800.0 -> To Version 3.0.0-experimental-27300.1886.260616-0840.2 Microsoft.WindowsAppSDK.InteractiveExperiences From Version 3.0.0-experimental-Rolling.20260525.1 -> To Version 3.0.0-experimental-Rolling.20260616.3 * Update dependencies from https://dev.azure.com/microsoft/LiftedIXP/_git/DCPP build 20260618.1 On relative base path root Microsoft.FrameworkUdk , Microsoft.ProjectReunion.InteractiveExperiences.TransportPackage From Version 3.0.0-experimental-27300.1878.260525-0800.0 -> To Version 3.0.0-experimental-27300.1887.260618-0800.0 Microsoft.WindowsAppSDK.InteractiveExperiences From Version 3.0.0-experimental-Rolling.20260525.1 -> To Version 3.0.0-experimental-Rolling.20260618.1 * Update dependencies from https://dev.azure.com/microsoft/LiftedIXP/_git/DCPP build 20260624.1 On relative base path root Microsoft.FrameworkUdk , Microsoft.ProjectReunion.InteractiveExperiences.TransportPackage From Version 3.0.0-experimental-27300.1878.260525-0800.0 -> To Version 3.0.0-experimental-27300.1889.260623-1720.0 Microsoft.WindowsAppSDK.InteractiveExperiences From Version 3.0.0-experimental-Rolling.20260525.1 -> To Version 3.0.0-experimental-Rolling.20260624.1 * Update dependencies from https://dev.azure.com/microsoft/LiftedIXP/_git/DCPP build 20260626.1 On relative base path root Microsoft.FrameworkUdk , Microsoft.ProjectReunion.InteractiveExperiences.TransportPackage From Version 3.0.0-experimental-27300.1878.260525-0800.0 -> To Version 3.0.0-experimental-27300.1890.260625-1640.0 Microsoft.WindowsAppSDK.InteractiveExperiences From Version 3.0.0-experimental-Rolling.20260525.1 -> To Version 3.0.0-experimental-Rolling.20260626.1 * Update dependencies from https://dev.azure.com/microsoft/LiftedIXP/_git/DCPP build 20260629.3 On relative base path root Microsoft.FrameworkUdk , Microsoft.ProjectReunion.InteractiveExperiences.TransportPackage From Version 3.0.0-experimental-27300.1878.260525-0800.0 -> To Version 3.0.0-experimental-27300.1891.260629-0710.2 Microsoft.WindowsAppSDK.InteractiveExperiences From Version 3.0.0-experimental-Rolling.20260525.1 -> To Version 3.0.0-experimental-Rolling.20260629.3 * Update dependencies from https://dev.azure.com/microsoft/LiftedIXP/_git/DCPP build 20260701.3 On relative base path root Microsoft.FrameworkUdk , Microsoft.ProjectReunion.InteractiveExperiences.TransportPackage From Version 3.0.0-experimental-27300.1878.260525-0800.0 -> To Version 3.0.0-experimental-27300.1892.260701-0945.0 Microsoft.WindowsAppSDK.InteractiveExperiences From Version 3.0.0-experimental-Rolling.20260525.1 -> To Version 3.0.0-experimental-Rolling.20260701.3 * Update dependencies from https://dev.azure.com/microsoft/LiftedIXP/_git/DCPP build 20260705.1 On relative base path root Microsoft.FrameworkUdk , Microsoft.ProjectReunion.InteractiveExperiences.TransportPackage From Version 3.0.0-experimental-27300.1878.260525-0800.0 -> To Version 3.0.0-experimental-27300.1893.260705-0915.0 Microsoft.WindowsAppSDK.InteractiveExperiences From Version 3.0.0-experimental-Rolling.20260525.1 -> To Version 3.0.0-experimental-Rolling.20260705.1 * Update dependencies from https://dev.azure.com/microsoft/LiftedIXP/_git/DCPP build 20260708.1 On relative base path root Microsoft.FrameworkUdk , Microsoft.ProjectReunion.InteractiveExperiences.TransportPackage From Version 3.0.0-experimental-27300.1878.260525-0800.0 -> To Version 3.0.0-experimental-27300.1894.260707-1730.0 Microsoft.WindowsAppSDK.InteractiveExperiences From Version 3.0.0-experimental-Rolling.20260525.1 -> To Version 3.0.0-experimental-Rolling.20260708.1 * Update dependencies from https://dev.azure.com/microsoft/LiftedIXP/_git/DCPP build 20260713.2 On relative base path root Microsoft.FrameworkUdk , Microsoft.ProjectReunion.InteractiveExperiences.TransportPackage From Version 3.0.0-experimental-27300.1878.260525-0800.0 -> To Version 3.0.0-experimental-27300.1896.260713-1015.0 Microsoft.WindowsAppSDK.InteractiveExperiences From Version 3.0.0-experimental-Rolling.20260525.1 -> To Version 3.0.0-experimental-Rolling.20260713.2 * Containment v2: migrate CompatibilityTests to 1-arg IsChangeEnabled --------- Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com> Co-authored-by: agniuks <41223743+agniuks@users.noreply.github.com> Co-authored-by: v-arlysenko <v-arlysenko+github@microsoft.com>
Forward-integrate main into release/dev/monobuild. Conflict resolution (4): - eng/Version.Details.xml + eng/Version.Dependencies.xml (modify/delete): kept DELETED. The monobuild eliminated Maestro / onboarded CPM (commit b8c3b63); neither file is referenced in the monobuild tree, and main's Maestro version bumps are consumed via CPM instead. - test/inc/WindowsAppRuntime.Test.Package.h: unioned the includes - kept OURS's <algorithm>/<string>/<vector> (used by std::vector<std::wstring>) and adopted main's <IsWindowsVersion.h>. - build/AzurePipelinesTemplates/WindowsAppSDK-BuildVSIX-Steps.yml (3 hunks): * Kept the monobuild's VSIX nuget download adaptation (SkipArtifactDownload gate, artifactName parameter, pipeline 190463, NightlyBranchName default refs/heads/release/dev/monobuild, single latest-from-branch mode). Did NOT adopt main's parallel refactor (UseLatestNightlyFromBranch two-mode toggle, $(OfficialPipelineID), pinned $(LatestOfficialBuildID), literal artifact name) - that is the standalone Foundation/Templates design and would revert the monobuild adaptation. * Kept OURS's IsMonobuild parameter; adopted main's OptionalVSIXVersion comment.
|
Azure Pipelines: There may be pipelines that require an authorized user to comment /azp run to run. |
Contributor
Author
|
/azp run |
|
Azure Pipelines: Successfully started running 1 pipeline(s). 1 pipeline(s) were filtered out due to trigger conditions. |
…672) The FI adopted main's Containment v2 migration (all IsChangeEnabled callsites moved to the 1-arg form), which requires the post-bump Microsoft.FrameworkUdk (adds the defaulted patchVersion template param). The monobuild carries FrameworkUdk and its coupled DCPP deps as manual ValueOrDefault fallbacks in Directory.Packages.props; they were still on the pre-bump May-25 train (.1878 / Rolling.20260525), so the 1-arg calls failed to compile with C2672 "no matching overloaded function found" (CompatibilityTests.cpp, RuntimeCompatibilityOptions.cpp) in the standalone Foundation PR build. Move all three DCPP deps to main's July-13 train (matching eng/Version.Details.xml): - Microsoft.FrameworkUdk: 27300.1878.260525-0800.0 -> 27300.1896.260713-1015.0 - Microsoft.ProjectReunion.InteractiveExperiences.TransportPackage: 27300.1878.260525-0800.0 -> 27300.1896.260713-1015.0 - Microsoft.WindowsAppSDK.InteractiveExperiences: Rolling.20260525.1 -> Rolling.20260713.2
Contributor
Author
|
/azp run |
|
Azure Pipelines: Successfully started running 1 pipeline(s). 1 pipeline(s) were filtered out due to trigger conditions. |
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
11 participants
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.
Forward-integration of
mainintorelease/dev/monobuild(2026-07-23).mainwas 21 commits ahead.Conflicts resolved (4):
eng/Version.Details.xml+eng/Version.Dependencies.xml(modify/delete) — kept deleted. The monobuild eliminated Maestro / onboarded CPM (commitb8c3b638); neither file is referenced in the monobuild tree, and main's Maestro version bumps are consumed via CPM instead.test/inc/WindowsAppRuntime.Test.Package.h— unioned the includes: kept OURS's<algorithm>/<string>/<vector>(used bystd::vector<std::wstring>) and adopted main's<IsWindowsVersion.h>.build/AzurePipelinesTemplates/WindowsAppSDK-BuildVSIX-Steps.yml(3 hunks):IsMonobuildparameter; adopted main'sOptionalVSIXVersioncomment.SkipArtifactDownloadgate,artifactNameparameter,pipeline: 190463,NightlyBranchNamedefaultrefs/heads/release/dev/monobuild, single latest-from-branch mode) and did not adopt main's parallel refactor (UseLatestNightlyFromBranchtwo-mode toggle,$(OfficialPipelineID), pinned$(LatestOfficialBuildID), literalWindowsAppSDK_Nuget_And_MSIXartifact name) — that is the standalone Foundation/Templates design and adopting it would revert the monobuild's deliberate adaptation. If the monobuild is meant to gain main's pinned-nightly mode, this hunk needs a manual merge instead.