[Wei Hu (live1206)]

Summary

• derive REST request-builder names from the original operation identity instead of mutable wrapper-specific back-compatibility state
• preserve the previous GA public method and request spelling, allowing a wrapper to expose GetUrl and consistently call the emitted CreateGetUrlRequest
• add a regression where a shipped wrapper preserves GetUrl, a later wrapper selects GetUri, and the final rendered REST provider still contains the request captured by the earlier wrapper
• preserve exact operation names while retaining normal C# identifier conversion for REST request helpers

This addresses the SDK generation failure described in #11708 where a generated wrapper called a REST request method that was absent from the final emitted provider. Retaining original operation identity also keeps distinct GetUrl and GetUri operations mapped to distinct REST request names without set-dependent collision handling.

Validation

• Microsoft.TypeSpec.Generator.ClientModel.Tests: 1,595 passed
• Local data-plane SDK regeneration: 47 Azure-branded and 5 unbranded libraries regenerated successfully, with no unexpected REST request-name diffs attributable to this change

[github-actions]

No changes needing a change description found.

[pkg-pr-new]

Open in StackBlitz

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

commit: 961f1ea

[Copilot]

Pull request overview

This PR stabilizes generated REST request-builder names when wrapper contracts preserve legacy Url methods.

Changes:

• Separates wrapper naming from REST request naming.
• Adds regression coverage for stable request generation.
• Updates REST request generation to use stable operation names.

Two critical issues remain in RestClientProvider.cs: an unused local causes a build failure, and normalized names can produce duplicate request method signatures.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

File	Summary
packages/http-client-csharp/generator/Microsoft.TypeSpec.Generator.ClientModel/test/Providers/ClientProviders/TestData/ClientProviderTests/TestBackCompatProviderDoesNotRenameRestRequestMethod/MockableTestResource.cs	Adds the wrapper back-compatibility fixture.
packages/http-client-csharp/generator/Microsoft.TypeSpec.Generator.ClientModel/test/Providers/ClientProviders/ClientProviderTests.cs	Adds regression coverage for stable request names.
packages/http-client-csharp/generator/Microsoft.TypeSpec.Generator.ClientModel/src/Providers/RestClientProvider.cs	Uses stable operation names; requires dead-code removal and collision handling.
packages/http-client-csharp/generator/Microsoft.TypeSpec.Generator.ClientModel/src/Providers/ClientProvider.cs	Centralizes operation-name normalization.

---

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

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated no new comments.

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated 1 comment.

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated 1 comment.

Suppressed comments (1)

packages/http-client-csharp/generator/Microsoft.TypeSpec.Generator.ClientModel/src/Providers/ClientProvider.cs:250

• For exact-name operations this returns the raw spelling, but REST helper names previously always applied ToIdentifierName() to the operation name. The existing snake_case_op exact-name case therefore regresses from CreateSnakeCaseOpRequest to CreateSnake_case_opRequest (and similar exact names can produce inconsistent helper identifiers). Keep using the current Operation.Name for exact-name/back-compat correctness, but apply the normal identifier conversion when constructing and comparing REST helper names.

            if (serviceMethod.IsExactName)
            {
                return operationName;

[Copilot]

Pull request overview

Copilot reviewed 6 out of 6 changed files in this pull request and generated no new comments.

[Copilot]

Pull request overview

Copilot reviewed 6 out of 6 changed files in this pull request and generated no new comments.

[Jorge Rangel (jorgerangel-msft)]

can we get a regen preview? Or If CI is not working, a pr from a local regen run?

[Wei Hu (live1206)]

can we get a regen preview? Or If CI is not working, a pr from a local regen run?

I did a local regen in #11753 (comment), will get the PR for it.

[Wei Hu (live1206)]

Refreshed the draft SDK regen PR from the latest azure-sdk-for-net main to remove the merge conflicts:

• DPG regen preview for TypeSpec #11753 Azure/azure-sdk-for-net#62486
• Azure-branded DPG: 47/47 passed
• Unbranded DPG: 5/5 passed
• Result: no generated SDK file changes

The date/time diffs in the earlier preview have now landed in Azure SDK main; with the latest base, the local regeneration for this PR is clean and produces no unexpected SDK diffs.

- by copilot

[Copilot]

Pull request overview

Copilot reviewed 6 out of 6 changed files in this pull request and generated no new comments.

[Copilot]

Pull request overview

Copilot reviewed 6 out of 6 changed files in this pull request and generated no new comments.

[Copilot]

Pull request overview

Copilot reviewed 6 out of 6 changed files in this pull request and generated no new comments.

[Wei Hu (live1206)]

Regen: Azure/azure-sdk-for-net#62526