Support multi-service C# clients without @client decorator

[Copilot]

When a TypeSpec library declares multiple @service-decorated namespaces without an explicit @client (the service/multiple-services spector scenario), TCGC emits one root client per service. The C# emitter's library-level logic didn't recognize this shape and resolved the package namespace to the first service's namespace instead of the shared parent, and the generator incorrectly shared a single ClientOptions instance across the per-service root clients.

Emitter changes (emitter/src/lib/utils.ts)

• getClientNamespaceString — when there are multiple @service namespaces (i.e. serviceNamespaces.length > 1) and the library does not contain a combined multi-service client, resolves the library namespace to the TypeSpec parent Namespace shared by those services (via firstNamespace.namespace from listAllServiceNamespaces) and passes it through the existing namespace-based helper path. The containsMultiServiceClient check is evaluated first so that a combined @client({ service: [...] }) under multiple nested @service namespaces (e.g. the service/multi-service spector spec) still resolves to the combined client's own namespace (e.g. Service.MultiService.Combined) rather than being truncated to the shared parent.
• containsMultiServiceClient — simplified to rootClients.some(isMultiServiceClient) so it only returns true when an individual client contains more than one service. The multi-root-multi-service case (multiple @service namespaces, each a separate single-service root) is handled directly in getClientNamespaceString via the serviceNamespaces.length > 1 check.

For the multiple-services spec, the library namespace now resolves to Service.MultipleServices instead of Service.MultipleServices.ServiceA, with ServiceAClient and ServiceBClient as sibling root clients each exposing their own Operations / SubNamespace sub-clients and per-service API version enums.

Generator changes (ClientOptionsProvider.cs)

• UseSingletonInstance — also returns false when the input library contains more than one ApiVersionEnum (i.e. spans multiple services). Previously, when multiple per-service single-service root clients existed, both would share the singleton ClientOptionsProvider, producing a single options class with only the first service's api version. Each root client now gets its own ClientOptions class (e.g. ServiceAClientOptions, ServiceBClientOptions).
• Constructor — now derives the service-specific api version enum(s) from the client's own api-version-typed parameters (p.IsApiVersion && p.Type is InputEnumType), falling back to the library-wide enum list only when the client has no typed api-version parameter. Previously, the constructor always scanned all library enums and (for single-service clients) picked the first one, causing ServiceBClientOptions to nest ServiceA's api version enum.

Tests

• emitter/test/Unit/client-converter.test.ts — new describe("multiple services without @client decorator", ...) block mirroring the spector scenario, asserting root count/names/namespaces, sub-client shape, per-service apiVersions, and that containsMultiServiceClient returns false (since no individual root client is itself a combined multi-service client). Also adds a regression test for the combined @client with nested @service namespaces scenario (multi-service spector spec) asserting the root namespace is the combined client's namespace (e.g. Service.MultiService.Combined).
• generator/.../ClientOptionsProviderTests.cs — new MultipleRootClients_WithoutClientDecorator_EachGeneratesItsOwnClientOptions test verifying that two per-service root clients each produce their own distinct ClientOptions type with the expected names and that each options class nests its own service-specific api version enum (verified via the enum's InputNamespace).

[pkg-pr-new]

Open in StackBlitz

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

commit: 71bf03f

[jorgerangel-msft]

@copilot there is a regression when regenerating our azure test libraries for this spec https://github.com/Azure/typespec-azure/blob/main/packages/azure-http-specs/specs/service/multi-service/client.tsp. The root namespace should be Service.MultiService.Combined. It is now truncating the Combined https://github.com/Azure/azure-sdk-for-net/blob/b20f4a432894f5f20685dc51ccf334f888572cec/eng/packages/http-client-csharp/generator/TestProjects/Spector/http/service/multi-service/src/Generated/Models/ServiceMultiServiceContext.cs. Also, the generated client options for service B is not correct https://github.com/Azure/azure-sdk-for-net/blob/b20f4a432894f5f20685dc51ccf334f888572cec/eng/packages/http-client-csharp/generator/TestProjects/Spector/http/service/multiple-services/src/Generated/ServiceBClientOptions.cs. It is using the api version enum from service A

[Copilot]

@copilot there is a regression when regenerating our azure test libraries for this spec https://github.com/Azure/typespec-azure/blob/main/packages/azure-http-specs/specs/service/multi-...

Fixed both regressions in 3dd66c4.

1. Namespace truncation for multi-service: Reordered checks in getClientNamespaceString so containsMultiServiceClient is evaluated before the serviceNamespaces.length > 1 branch. A combined @client({ service: [...] }) spanning multiple @service namespaces now correctly resolves to the combined client's namespace (e.g. Service.MultiService.Combined) instead of the shared parent. Added an emitter regression test for this.

2. ServiceBClientOptions using ServiceA's api version: The ClientOptionsProvider constructor was scanning all api-version enums in the library and picking the first one for single-service clients. Now it first looks at the client's own api-version parameter(s) for the enum type (falling back to the library enum list only when the client has no typed api-version parameter, to preserve existing test setups). Strengthened the existing unit test to assert each root client's options nests its own service-specific api version enum (verified via the enum's InputNamespace).

All 1312 ClientModel generator tests and 201 emitter tests pass.