[csharp] Auto-resolve ModelProvider.BaseModelProvider from BaseType via CSharpTypeMap

[Copilot]

ModelProvider.BuildBaseType is virtual and emitters override it to redirect the C# base class (e.g., to a framework type they own), but BuildBaseModelProvider was private, so BaseModelProvider kept walking InputModelType.BaseModel and diverged from the generated class hierarchy. Visitors traversing BaseModelProvider would see "inherited" properties from a parent that is no longer the actual C# base.

Changes

• Inverted the dependency between BuildBaseType and BuildBaseModelProvider so that BaseType is the source of truth and BaseModelProvider derives from it:
  • BuildBaseType now resolves the C# base CSharpType directly from CustomCodeView.BaseType (including the empty-namespace TypeProvidersByName fallback with the CreateModel warm-up loop, plus a CSharpTypeMap fallback so a customized base that matches an existing generated ModelProvider returns that provider's Type) or from _inputModel.BaseModel via CreateModel(...).Type. It no longer reads BaseModelProvider, so the previous chicken-and-egg cycle is broken.
  • BuildBaseModelProvider remains private and now looks up BaseType in CSharpTypeMap, returning the registered ModelProvider if any, else null. No recursion since BuildBaseType doesn't read BaseModelProvider.
• Unit tests in ModelProviderTests covering:
  • Override-only-BuildBaseType redirect to another generated model auto-resolves BaseModelProvider via the map.
  • Override-only-BuildBaseType redirect to a framework / external type auto-resolves BaseModelProvider to null.
  • Override-only-BuildBaseType redirect to a non-ModelProvider TypeProvider registered in CSharpTypeMap auto-resolves BaseModelProvider to null.
  • Default case (no overrides) resolves both consistently.
  • No-base-model case yields null for both.
• Tests use MockHelpers.LoadMockGenerator(createModelCore: ...) to mock the type factory so it returns the custom ModelProvider subclass for the relevant InputModelType, matching the pattern in existing tests like InputLibraryVisitorTests.

Example: emitter redirecting to a framework base

Emitters now only need to override BuildBaseType. BaseModelProvider is automatically null because the framework CSharpType isn't a ModelProvider in CSharpTypeMap:

internal class MyModelProvider : ModelProvider
{
    private readonly CSharpType _frameworkBase;

    public MyModelProvider(InputModelType inputModel, CSharpType frameworkBase)
        : base(inputModel) => _frameworkBase = frameworkBase;

    protected override CSharpType? BuildBaseType() => _frameworkBase;
    // No need to also override BuildBaseModelProvider — it auto-resolves to null.
}

If BuildBaseType is redirected to another generated model's CSharpType, BaseModelProvider automatically resolves to that model's ModelProvider. BaseType and BaseModelProvider stay in lock-step in all cases.

[pkg-pr-new]

Open in StackBlitz

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

commit: e35a22e

[github-actions]

No changes needing a change description found.

[Copilot]

@copilot what about this check? Why are we not porting the full checks over?

That check was an early-exit in the old BuildBaseModelProvider to prevent fall-through to walking _inputModel.BaseModel once we knew the customized base was an external type. In the new BuildBaseType it's structurally redundant: the entire CustomCodeView?.BaseType != null branch always returns (either via the empty-namespace TypeProvidersByName lookup, the new CSharpTypeMap fallback, or the final return customBase; at line 228), so we never fall through to _inputModel.BaseModel when there's a customized base. Adding if (!string.IsNullOrEmpty(customBase.Namespace)) return null; would actually break the external-type case — BuildBaseType is now the source of truth for the C# base, so for an external custom base we want to return customBase, not null. BuildBaseModelProvider then returns null for it (because the CSharpTypeMap entry, if present, is a SystemObjectTypeProvider, not a ModelProvider), giving the same end result the old code achieved via the explicit namespace check.

[jorgerangel-msft]

@copilot can we add a test that validates that if BuildBaseType is overridden with a custom TypeProvider (not a ModelProvider) that BaseModelProvider returns null?

[Copilot]

@copilot can we add a test that validates that if BuildBaseType is overridden with a custom TypeProvider (not a ModelProvider) that BaseModelProvider returns null?

Added in a856150. The new test OverridingBuildBaseType_AutoResolvesBaseModelProviderToNullForNonModelTypeProvider registers a non-ModelProvider TypeProvider (NonModelTypeProvider) in CSharpTypeMap and overrides BuildBaseType to return its Type — BaseType resolves to the redirected CSharpType and BaseModelProvider is null since the registered provider is not a ModelProvider.