Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Copilot-Session: cf5c9dac-de56-477f-9858-541b9fec0178

Fixes: #19503

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

…13 On relative base path root Microsoft.DeveloperControlPlane.darwin-amd64 , Microsoft.DeveloperControlPlane.darwin-arm64 , Microsoft.DeveloperControlPlane.linux-amd64 , Microsoft.DeveloperControlPlane.linux-arm64 , Microsoft.DeveloperControlPlane.linux-musl-amd64 , Microsoft.DeveloperControlPlane.windows-amd64 , Microsoft.DeveloperControlPlane.windows-arm64 From Version 0.25.12 -> To Version 0.25.13 (#19528)

Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>

…ingetcreate (#19509)

* fix(release): install .NET 9 for wingetcreate

WinGet publication fails before submit because the latest standalone
wingetcreate targets .NET 9 and is framework-dependent, while the
release agent image has no compatible runtime:

wingetcreate.exe : You must install or update .NET to run this application.

Install the .NET 9 runtime in the gated submission path before launching
wingetcreate. Exercise the latest executable with `info` in normal WinGet
preparation builds so future runtime incompatibilities fail before release.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

* fix(release): exercise wingetcreate in dry runs

The WinGet setup steps were gated by live production submission, so dry
runs skipped both the .NET 9 runtime installation and the wingetcreate
startup check. That prevented a safe branch run from proving that the
latest wingetcreate executable could launch.

Run UseDotNet and wingetcreate info whenever the WinGet job is selected,
while retaining the live-only gate on URL validation and submission.
This validates runtime compatibility without opening an upstream PR.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

---------

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

)

* Remove pipeline-scoped Publish-Build-Assets group

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

* Pin Azure Identity for VSCE installs

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

Copilot-Session: dbe46f58-0f31-4540-a647-0d0e77bea4f1

* Clarify pipeline workaround conditions

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

Copilot-Session: dbe46f58-0f31-4540-a647-0d0e77bea4f1

* Document VSCE dependency pin

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

Copilot-Session: dbe46f58-0f31-4540-a647-0d0e77bea4f1

---------

Co-authored-by: Adam Ratzman <adam@adamratzman.com>
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: dbe46f58-0f31-4540-a647-0d0e77bea4f1

#19557)

* Exclude unused hex1bpty.exe from published CLI archives

Hex1b ships a hex1bpty.exe PTY host in its win-x64/win-arm64 native assets.
Aspire never takes that path: DCP owns every PTY we surface and
Aspire.TerminalHost only proxies the byte stream DCP already produces, so the
helper is ~5 MB of dead weight in each Windows CLI archive and inside every
Windows aspire.exe bundle payload. It also shows up as an unexplained second
executable in the winget submission, where every binary in the archive is run
through executable and malware checks.

Filter it out of publish for src/ projects. Test projects are untouched because
they drive real terminals through Hex1b.Automation, which does need the helper.
Unix keeps libhex1binterop.{so,dylib}, the termios/ioctl shim the TUI P/Invokes.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

* Update PatchVersion to 2 in Versions.props

---------

Co-authored-by: Mitch Denny <midenn@microsoft.com>
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Jose Perez Rodriguez <joperezr@microsoft.com>