| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
Migrate the sample to Foundry source (ZIP) deployment as the default: add azure.yaml with codeConfiguration (remote_build, dotnet_10) and the tool-generated .agentignore, make the csproj self-contained (single target, CPM off, published PackageReferences), and simplify Program.cs to the pristine end-user hosting path. Container files are kept for now; contributor and remaining samples handled in follow-ups.
…ed-ChatClientAgent to source (ZIP) Foundry.Hosting: AddFoundryResponses now binds Kestrel to FoundryEnvironment.Port (the PORT env var, default 8088) for a plain WebApplication.CreateBuilder (Tier 3) host, mirroring AgentHostBuilder. This lets a source/ZIP-deployed .NET agent pass the readiness probe with no Dockerfile. It respects an explicit ASPNETCORE_URLS override and is idempotent. Adds FoundryListenPortTests plus a serialized env-var collection. Hosted-ChatClientAgent: migrate to source (ZIP) deploy as the default. Add azure.yaml with codeConfiguration (remote_build, dotnet_10) and the tool-generated .agentignore, make the csproj self-contained (single target, CPM off) with a local Directory.Packages.props, embed the local-dev per-agent route so the Using-Samples REPL can reach the local server, and rewrite the README around the azd flow. Documents AZURE_TOKEN_CREDENTIALS=dev for local runs. Using-Samples/SimpleAgent: fix the per-agent endpoint scheme rewrite so the local HTTP dev port is preserved (the policy now lives on the per-agent ProjectOpenAIClientOptions that actually serves the request).
…and the local-only agent route Zip/code deploy runs the sample as a plain ASP.NET app, so the Foundry readiness port was never bound and every invoke returned HTTP 424 session_not_ready. The first attempt skipped the binding when ASPNETCORE_URLS was already set, but the .NET base image always sets it to port 80, so the skip always tripped. Kestrel ListenAnyIP overrides ASPNETCORE_URLS, so the binding is now unconditional and PORT stays the only knob. Sample cleanup for zip deploy: * Remove Dockerfile, Dockerfile.contributor, agent.manifest.yaml and agent.yaml. Source deploy needs none of them. * Remove LocalDevEndpoint.cs and the invented per-agent local route. The local server already serves the standard POST /responses route, so the client can reach it directly. * Trim .env.example: the port and environment variables are no longer needed. * Exclude .checkpoints/ from the upload so local session state does not ship. SimpleAgent now asks at startup whether to chat with the local server or the deployed agent, the same choice azd ai agent invoke exposes through --local. Local uses an OpenAI responses client pointed at http://localhost:8088; Foundry uses the per-agent endpoint. Add scripts/New-ContributorStage.ps1, which stages a sample to a temp folder with the local Agent Framework source packed into a feed inside the upload, so contributors can deploy framework changes through the same azd flow end users run.
| Back | FazBrowse Home | New Git URL |
Motivation & Context
Source (code / ZIP) deploy is now the default for Python and .NET hosted agents: you upload your sources and the platform builds and runs them, with no Dockerfile to author and no container registry to manage. The .NET samples still only showed the container path, so this change reorients them around ZIP deploy and makes deploying an Agent Framework hosted agent a much simpler experience.
Description & Review Guide
What are the major changes?
Hosted-ChatClientAgent now deploys from source through a single unified azure.yaml, and a sibling Hosted-ChatClientAgent-Dockerfile keeps the container path for anyone who needs control over the runtime image.
Along the way, a few quality and simplicity improvements:
What is the impact of these changes?
Inside a Foundry container, a plain WebApplication host calling AddFoundryResponses now listens on FoundryEnvironment.Port. Override with PORT. Hosts using AgentHostBuilder already behaved this way, and a host running outside Foundry keeps the addresses it resolved from configuration.
What do you want reviewers to focus on?
The listen-port gate: it keys off FOUNDRY_HOSTING_ENVIRONMENT, read directly rather than through the cached FoundryEnvironment.IsHosted. Inside Foundry it cannot be guarded on ASPNETCORE_URLS (the .NET base image always sets it to port 80) nor on the presence of PORT (the platform sets that only for a non-default port).
Contribution Checklist