Tags: microsoft/WindowsAppSDK
Tags
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
Enable item templates for metapackage and WinUI projects (#6604) * Add comment to ProjectFinishedGenerating * Show WinUI item templates under split WinUI package (#6593) VS 'Add New Item' item templates gated visibility on the 'WindowsAppSDK' project capability, which is only contributed by the meta Microsoft.WindowsAppSDK package. Projects referencing only the split Microsoft.WindowsAppSDK.WinUI package get the 'WinUI' capability instead, so the templates never appeared. Relax AppliesTo in all 13 item templates to accept either capability: 'CSharp + (WindowsAppSDK | WinUI)' and 'VisualC + (WindowsAppSDK | WinUI)'. Parentheses are required because '+'/'&' (AND) bind tighter than '|' (OR). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Enable item templates for metapackage and WinUI projects (#6604) * Add comment to ProjectFinishedGenerating * Show WinUI item templates under split WinUI package (#6593) VS 'Add New Item' item templates gated visibility on the 'WindowsAppSDK' project capability, which is only contributed by the meta Microsoft.WindowsAppSDK package. Projects referencing only the split Microsoft.WindowsAppSDK.WinUI package get the 'WinUI' capability instead, so the templates never appeared. Relax AppliesTo in all 13 item templates to accept either capability: 'CSharp + (WindowsAppSDK | WinUI)' and 'VisualC + (WindowsAppSDK | WinUI)'. Parentheses are required because '+'/'&' (AND) bind tighter than '|' (OR). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Enable item templates for metapackage and WinUI projects (#6604) * Add comment to ProjectFinishedGenerating * Show WinUI item templates under split WinUI package (#6593) VS 'Add New Item' item templates gated visibility on the 'WindowsAppSDK' project capability, which is only contributed by the meta Microsoft.WindowsAppSDK package. Projects referencing only the split Microsoft.WindowsAppSDK.WinUI package get the 'WinUI' capability instead, so the templates never appeared. Relax AppliesTo in all 13 item templates to accept either capability: 'CSharp + (WindowsAppSDK | WinUI)' and 'VisualC + (WindowsAppSDK | WinUI)'. Parentheses are required because '+'/'&' (AND) bind tighter than '|' (OR). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Fix MICROSOFT_WINDOWSAPPRUNTIME_BASE_DIRECTORY leaking to child proce… …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>
Add Templates PR validation pipeline (dotnet new + VSIX) (#6526) Adds `WindowsAppSDK-Templates-PR` to validate changes under `dev/Templates/`. For developers to check if their changes would break the build of WinUI templates. **What it runs** - Build a dotnet new templates NuGet of the changed code for local tests (no signing, no publish) - Builds 4 VSIXes (Cs/Cpp x Standalone/Component) of the changed code against the latest nightly nupkg from `main`.
PreviousNext