[Bug]: Required client initialization parameters generate unintended ClientOptions in C#

[JonathanCrd]

Describe the bug

When generating a client using @@clientInitialization with a required initialization parameter, the C# generator is automatically introducing a <ClientName>ClientOptions parameter into the generated constructor — even when the parameter is required and not intended to be modeled as part of an options type.

This breaks alignment with existing GA client patterns in Azure.Search.Documents and may indicate a bug in the generator logic that determines when a separate client options class is required in multi-client scenarios.

Reproduction

We are attempting to generate a client with a required initialization parameter (knowledgeBaseName) using TypeSpec:

model KnowledgeBaseRetrievalClientOptions {
  @paramAlias("knowledgeBaseName")
  knowledgeBaseName: string;
}

@client({
  name: "KnowledgeBaseRetrievalClient",
  service: Search,
})
namespace KnowledgeBaseRetrievalClient {}

@@clientInitialization(KnowledgeBaseRetrievalClient, {
  parameters: KnowledgeBaseRetrievalClientOptions,
});

Expected Behavior

The generator should inline the required initialization parameter and produce a constructor like:

public KnowledgeBaseRetrievalClient(string knowledgeBaseName)

(or equivalent overloads with credentials/endpoints)

Actual Behavior

The generator produces:

public KnowledgeBaseRetrievalClient(
    Uri endpoint,
    string knowledgeBaseName,
    AzureKeyCredential credential,
    KnowledgeBaseRetrievalClientOptions options)

Even though:

• knowledgeBaseName is required
• We did not explicitly intend for an options type to be introduced
• Existing GA Search clients (SearchClient, SearchIndexClient, etc.) rely on a shared custom options model (SearchClientOptions)

This results in:

• A generated <ClientName>ClientOptions type that is not aligned with existing SDK GA patterns
• Inconsistent constructor signatures across clients in the same library
• Additional customization needed to maintain backward compatibility

Hypothesis

The generator logic that determines whether a separate client options class is required in multi-client scenarios may not be correctly ignoring required initialization parameters when making this decision.

Required parameters should not impact whether a separate client options type is generated.

Environment

• TypeSpec http-client-csharp generator
• Azure.Search.Documents TSP migration scenario

🤖 Generated with Copilot

---

Checklist

• Follow our Code of Conduct
• Check that there isn't already an issue that request the same bug to avoid creating a duplicate.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion.
• The provided reproduction is a minimal reproducible example of the bug.

[jorgerangel-msft]

Isn't having a ClientOptions type for service clients part of our .NET guidelines? Is Search an exception here or is this not a service client?