Fix duplicate API version field names for multi-service clients with colliding namespaces

[Copilot]

ClientOptionsProvider.BuildVersionProperties() and ApiVersionEnumProvider.BuildName() both derived names from inputEnum.Namespace via BuildNameForService(), which extracts only the last namespace segment. When two services have different full namespaces but the same last segment, identical names are generated, crashing ClientProvider.BuildMethods() at Fields.ToDictionary(). This blocks the Azure management plane generator for multi-service SDKs like Azure Compute.

Changes

• ApiVersionEnumProvider.cs: For multi-service clients, use the full namespace (namespace.ToIdentifierName() + "Version") instead of BuildNameForService() to derive service version enum names. This guarantees uniqueness since different services always have different full namespaces.
• ClientOptionsProvider.cs: For multi-service clients, use the full namespace (inputEnum.Namespace.ToIdentifierName() + "ApiVersion") instead of BuildNameForService() to derive version property names. Also simplified constructor parameter naming to use the enum name directly (serviceVersionEnum.Name.ToVariableName()).
• ClientHelper.cs / ClientHelperTests.cs: Removed the now-unused BuildNameForService helper method and its tests, since both call sites were replaced with full-namespace-based naming.
• ClientProviderTests.cs: Regression test with two services having different full namespaces but the same last segment (Azure.ServiceOne.Tests vs Azure.ServiceTwo.Tests), verifying no crash and distinct field names (_azureServiceOneTestsApiVersion, _azureServiceTwoTestsApiVersion).
• ClientOptionsProviderTests.cs: Test validating that generated service version enums have no naming collisions when namespaces share the same last segment.
• ApiVersionEnumProviderTests.cs: Updated assertions to match new full-namespace-based enum naming pattern.
• Golden test data files: Updated expected output to reflect the new full-namespace-based naming pattern.

// Before: "Sample.ServiceA" → last segment "ServiceA" → enum "ServiceAVersion", property "ServiceAApiVersion"
//         (collides when last segments match across different namespaces)
// After:  "Sample.ServiceA" → full namespace "SampleServiceA" → enum "SampleServiceAVersion", property "SampleServiceAApiVersion"
//         (guaranteed unique since full namespaces differ)

Original prompt

---

This section details on the original issue you should resolve

<issue_title>[CSharp] ClientProvider.BuildApiVersionFields produces duplicate field names for multi-service clients</issue_title>
<issue_description>## Bug Report

Description

When a multi-service client is created via @client({ service: [ServiceA, ServiceB] }), ClientProvider.BuildApiVersionFields() can produce duplicate field names, causing BuildMethods() to crash with:

An item with the same key has already been added. Key: serviceTestsApiVersion
   at Dictionary2.Add(TKey key, TValue value)
   at Enumerable.ToDictionary(...)
   at ClientProvider.BuildMethods()

Impact

This crashes the Azure management plane generator (@azure-typespec/http-client-csharp-mgmt) when generating multi-service SDKs such as Azure Compute (which combines 4 services via @client({ service: [Compute, ComputeDisk, ComputeGallery, ComputeSku] })).

The mgmt generator does not use the ClientProvider or its API version fields at all — it replaces them with its own ARM resource-based client hierarchy. However, the crash occurs during ClientProvider.BuildMethods() before the mgmt generator gets a chance to override it, so the mgmt generator cannot work around this without patching the base ClientProvider.

Root Cause

In ClientOptionsProvider.BuildVersionProperties(), the property name for each service version is computed via:

string name = _inputClient.IsMultiServiceClient 
    ? ClientHelper.BuildNameForService(inputEnumType.Namespace, "Service", "ApiVersion") 
    : "Version";

When two services have namespaces that reduce to the same identifier (e.g. both share a common namespace segment from the C# output namespace), BuildNameForService produces the same property name for both services.

Then in ClientProvider.BuildApiVersionFields(), when VersionProperties.Count > 1:

string name = (count > 1) ? ("_" + propertyProvider.Name.ToVariableName()) : text;

Both services get the same field name (e.g. _serviceTestsApiVersion), and Fields.ToDictionary() in BuildMethods() crashes on the duplicate key.

Reproduction

Two ARM services combined via @client, with the output C# namespace causing name collisions:

ServiceOne/main.tsp:

@armProviderNamespace
@service(#{ title: "ServiceOne" })
@versioned(ServiceOne.Versions)
namespace ServiceOne;

enum Versions { v2024_01_01: "2024-01-01" }
// ... resource definition ...

ServiceTwo/main.tsp:

@armProviderNamespace
@service(#{ title: "ServiceTwo" })
@versioned(ServiceTwo.Versions)
namespace ServiceTwo;

enum Versions { v2024_06_01: "2024-06-01" }
// ... resource definition ...

client.tsp:

@client({ name: "MultiServiceClient", service: [ServiceOne, ServiceTwo] })
namespace MultiServiceCombine;

tspconfig.yaml with namespace Azure.Generator.MgmtTypeSpec.MultiService.Tests

Expected Behavior

Each service should get a unique field name for its API version field, even when namespace segments collide.

Actual Behavior

Both services produce the same field name serviceTestsApiVersion, causing ToDictionary to crash.</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes [CSharp] ClientProvider.BuildApiVersionFields produces duplicate field names for multi-service clients #10055

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[pkg-pr-new]

Open in StackBlitz

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

commit: b8b550e