[sarah (satvu)]

Why this is needed

Host 4.1048.200-preview.2 moved to the RID-pointer workload model: the logical Azure.Functions.Cli.Workloads.Host package selects a physical package such as Azure.Functions.Cli.Workloads.Host.win-x64, whose metadata declares runtimeIdentifier: win-x64.

The physical package still places its payload under tools/any, though. Because the CLI uses the declared RID to calculate the installed content root, it looks for the executable at:

tools/win-x64/Azure.Functions.Cli.Workloads.Host.exe

but the package contains it at:

tools/any/Azure.Functions.Cli.Workloads.Host.exe

Installation and func workload list succeed because the pointer and RID metadata are valid, but every func start flow fails when the CLI tries to launch the missing executable. This affects all language stacks because they share the same Host workload.

What changed

• pack each RID-specific Host payload under tools/<rid> so its file layout matches its package ID and runtimeIdentifier metadata
• bump the corrective Host workload release to 4.1048.200-preview.3
• document that release packages must be built with PackAllRids=true and SelfContained=true
• correct the Host release-note versions to match the actual package versions

Release impact

After this merges, publish the logical Host pointer package and all generated RID implementation packages at 4.1048.200-preview.3.

The underlying Functions Host dependency remains 4.1048.200, so no CLI, worker, or stack release is required.

Validation

• dotnet restore
• dotnet test test\Workloads\Host.Tests\Workloads.Host.Tests.csproj -c Release --no-restore — 50 passed
• release-mode dotnet pack with PackAllRids=true produced the logical package plus six RID packages without warnings
• verified the win-x64 nupkg contains tools/win-x64/Azure.Functions.Cli.Workloads.Host.exe and no tools/any payload
• released CLI 5.0.0-preview.3 installed Host 4.1048.200-preview.3 from disposable BaGet, selected the win-x64 implementation, started the Host, and returned HTTP 200 with state Running

[Copilot]

Copilot review overview

🟡 Changes recommended

Release instructions omit SelfContained=true, which may produce unusable framework-dependent packages.

Get a fresh assessment by requesting another Copilot review.

Review effort: Lite
Findings: 1

Open (1)

• Ensure RID packages remain self-contained during release builds · New

What changed in this PR

Fixes Host workload packaging so RID-specific payloads are placed under tools/<rid>, with updated versioning and documentation.

Changes:

• Updates RID-specific package layout.
• Bumps the Host workload version.
• Revises packaging guidance and release notes.

File	Summary
src/​Workloads/​Host/​release_notes.md	Updates release notes and versions.
src/​Workloads/​Host/​README.DEV.md	Documents RID-specific packaging.
src/​Workloads/​Host/​Directory.Version.props	Bumps the package version.
src/​Workloads/​Host/​Build.Inner.targets	Places payloads under the RID-specific tools path.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Copilot review overview

🔵 Needs a closer look

DeployForDebug still copies rebuilt output to tools/any, which can cause local debugging to launch a stale executable.

Review effort: Lite
Findings: None

Resolved since last review (1)

• Ensure RID packages remain self-contained during release builds

Previously missed (1)

In code that hasn't changed since last review

DeployForDebug still copies Host output to stale tools/any path

src/​Workloads/​Host/​Build.Inner.targets:28

This moves the installed implementation payload to tools/<rid>, but DeployForDebug still copies rebuilt Host output to tools/any (eng/build/WorkloadDebug.targets:39,79-82). Because the installed Host entry carries its runtime identifier, func start resolves tools/<rid>, so subsequent local debug builds will continue launching the stale executable. Update the debug deployment path to use the RID-aware content root as part of this change.

[sarah (satvu)]

Copilot review overview

Previously missed (1)
In code that hasn't changed since last review

DeployForDebug still copies Host output to stale tools/any path

I traced through DeployForDebug, and it looks like it doesn’t actually copy the Host output to tools/any today. It only runs for FuncCliWorkload; the Host either has no package type during a normal build or is FuncCliWorkloadRidPackage for a RID build. It also has IncludeBuildOutput=false, so there wouldn’t be a payload to copy through this path anyway.

The Host does not use this workflow. Host local iteration uses FUNC_HOST_CONTENT_ROOT, pointing the CLI directly at the freshly built Host output. That is why the review’s DeployForDebug concern does not affect this Host packaging fix.