Skip to content

fix(http-client-csharp): preserve constructors with approved framework defaults - #12311

Closed
Wei Hu (live1206) wants to merge 1 commit into
microsoft:mainfrom
live1206:fix/12304-network-constructor-preservation
Closed

Wei Hu (live1206) wants to merge 1 commit into
microsoft:mainfrom
live1206:fix/12304-network-constructor-preservation

Conversation

@live1206

Copy link
Copy Markdown
Contributor

Summary

Fixes #12304 (the Network constructor follow-up), split out of #12310.

  • Preserve a historical concrete-model constructor when the current initialization constructor adds an inherited framework value argument.
  • Chain the legacy overload to the current constructor using a typed default only after explicit downstream approval. The capability defaults to false and cannot bypass required source/model-owned properties or ambiguous-target rejection.
  • Copy historical parameter metadata without mutating the baseline; reuse the current constructor's initialization and argument validation.

Independence and scope

Design status: constructor/defaulting policy is still under discussion. This draft isolates the existing proposal for review; it is not a finalized decision about how current handwritten constructors should control generation.

This PR targets main independently of #12310 and does not include its mapped-hierarchy/property-projection changes. The constructor fixture supplies an already-restored flat hierarchy; actual flat-base discovery remains #12303.

The downstream management generator must opt into the known historical default alongside Azure/azure-sdk-for-net#63998 before the real Network cleanup uses this path. No real Network GA ApiCompat run, SDK regeneration, or inherited ARM-envelope JSON-roundtrip validation is claimed.

Change-specific validation

  • Reproduce the missing properties-only overload on the unchanged generator with the same portable fixture.
  • Compile and execute generated legacy/current overloads to check default/explicit Location, Properties identity, exactly-once base initialization, and null-argument validation.
  • Verify opt-out, required wire/model-owned property rejection, multiple initialization-target rejection, and unchanged baseline metadata.
  • On unchanged production code, the same fixture produced one expected missing-overload failure and five passing controls; after the isolated change, all six Network cases pass.
  • After the split: 114/114 focused Network/back-compat checks, 2,923/2,923 core Generator tests, and 2,455/2,455 ClientModel tests passed, with no skipped tests.

- by copilot

@pkg-pr-new

pkg-pr-new Bot commented Oct 20, 2026

Copy link
Copy Markdown

Open in StackBlitz

npm i https://pkg.pr.new/@typespec/http-client-csharp@12311

commit: d24c149

@github-actions

Copy link
Copy Markdown
Contributor

No changes needing a change description found.

@live1206

Copy link
Copy Markdown
Contributor Author

Withdrawing this framework-defaulting proposal in favor of the revised plan: keep the known SDK legacy constructor and use existing CodeGenSuppress for explicit replacement, then investigate a narrow custom-constructor restoration-guard relaxation in #12310 if it remains small. That relaxation is not implemented yet; the flat-base and real-SDK validation prerequisites still apply.

The updated cleanup handoff is Azure/azure-sdk-for-net#63992 (comment).

- by copilot

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

emitter:client:csharp Issue for the C# client emitter: @typespec/http-client-csharp

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[http-client-csharp] Support restoring last-contract bases over an existing framework-mapped base

1 participant