C# generator should fully support inheritable system model replacements

[live1206]

Description

The C# generator has SystemObjectModelProvider, which is a useful building block for mapping an input model to an existing framework/system model while still allowing derived generated models to use it as BaseModelProvider. However, Azure management-plane generation still needs a custom MPG visitor (InheritableSystemObjectModelVisitor) to repair several behaviors after mapping ARM common types like Resource, ProxyResource, and TrackedResource to framework types such as ResourceData and TrackedResourceData.

We would like MTG/ClientModel to provide first-class support for inheritable system model replacement so MPG can remove or significantly shrink this visitor.

Current workaround in MPG

In Azure/azure-sdk-for-net#56634, MPG uses InheritableSystemObjectModelVisitor to:

1. Register framework CSharpType aliases in CSharpTypeMap so custom-code base types like TrackedResourceData resolve back to the mapped SystemObjectModelProvider.
2. Repair SystemObjectModelProvider namespace after generic namespace visitors run.
3. Remove model factory methods returning known framework management types.
4. Manually remove inherited properties from derived models, including wire-name matches such as a derived Name0 property whose serialized name is name, because the framework base already owns Name.
5. Strip orphaned virtual modifiers after removing inherited duplicate properties.

Gap in MTG today

SystemObjectModelProvider : ModelProvider already helps with some inheritance behavior:

• It can serve as BaseModelProvider.
• It sets ShouldSkipDerivedModelProperties = true.
• It does not emit fields or serialization providers for the framework type.
• ModelProvider.BuildProperties() skips derived properties whose C# property name matches a base property from a provider marked ShouldSkipDerivedModelProperties.

But this is not enough for ARM-style common types:

1. Wire-name based property dedup is missing

MTG skips inherited properties by C# property name. MPG also needs wire-name equivalence.

Example:

• Framework base has Name with wire name name.
• Derived input model has a generated C# property Name0 but serialized/wire name name.
• The derived property should be removed because the framework base already represents that wire property.

Without this, generated output can duplicate ARM base properties as renamed properties like Name0.

2. Framework/non-framework CSharpType alias lookup is fragile

Custom code can resolve a base type like TrackedResourceData as a framework CSharpType, while the mapped system provider may be keyed differently. MTG should make the system replacement discoverable under all equivalent CSharpType forms, or compare framework/system replacement types consistently in BuildBaseModelProvider().

3. Namespace rewriting should not corrupt system providers

Generic namespace visitors can rewrite provider namespaces to the SDK namespace. A system/framework provider should keep its framework namespace or otherwise be immune to normal generated-model namespace rewriting.

4. Model factory methods should not be emitted for framework replacements

If an input model is replaced by a framework/system type, model factory methods returning that framework replacement should be skipped by default. MPG currently filters them out.

5. Constructor/field/serialization behavior should fully account for system bases

Once a generator maps an input model to an inheritable framework base, derived models should not duplicate inherited fields/properties/constructor parameters/serialization overrides, including the wire-name equivalence case above.

Desired behavior

A generator should be able to register something equivalent to:

Known ARM model "TrackedResource" -> framework type TrackedResourceData
Known ARM model "Resource" -> framework type ResourceData

Then MTG should handle derived generated models correctly without a management-plane visitor manually walking and editing properties.

Suggested test case

Add a ClientModel/MTG test with:

• A system base input model representing ResourceData or TrackedResourceData, with properties like id, name, type, tags, location.
• A derived generated model with a property named name0 whose serialized name is name, plus a normal service-specific property.
• The base model mapped to a SystemObjectModelProvider/framework type.

Expected:

• The derived generated model does not emit Name0.
• It does not duplicate base fields or constructor parameters.
• Serialization methods call/override appropriately for a system base.
• Model factory methods for the framework replacement type are not generated.
• The system provider keeps the framework namespace.

Context

This is needed to simplify Azure management-plane generation and eventually remove more of InheritableSystemObjectModelVisitor from MPG.

[github-actions]

🎯 Issue Triage

This feature request asks the C# generator (MTG/ClientModel) to provide first-class support for inheritable system model replacements, so that Azure management-plane generation (MPG) can remove or significantly reduce its custom InheritableSystemObjectModelVisitor.

Category: Feature Request

Area: emitter:client:csharp, emitter-framework

🔍 Analysis

The issue identifies five specific gaps in SystemObjectModelProvider today:

1. Wire-name property dedup — MTG deduplicates inherited properties by C# name only; ARM-style types need wire-name equivalence (e.g., a generated Name0 with wire name name should be suppressed when the framework base already owns name).
2. CSharpType alias lookup — Custom code base types (e.g., TrackedResourceData) may not resolve consistently to the mapped SystemObjectModelProvider key.
3. Namespace rewriting — Generic namespace visitors can overwrite a system/framework provider's namespace with the SDK namespace.
4. Model factory suppression — Factory methods returning framework replacement types should be skipped by default.
5. Constructor/field/serialization — Derived models should not duplicate inherited members (including the wire-name case) when a system base is set.

The issue includes a concrete suggested test case and references the upstream workaround in azure-sdk-for-net#56634. No duplicates were found.

📝 Suggested next steps

• Extend ModelProvider.BuildProperties() to also suppress derived properties by wire name when ShouldSkipDerivedModelProperties is set.
• Make SystemObjectModelProvider register all equivalent CSharpType forms (or normalize comparison in BuildBaseModelProvider()).
• Protect system/framework providers from generic namespace rewriting visitors.
• Skip model factory method emission when the return type is a framework system replacement.
• Add the MTG test described in the issue (system base with id/name/type/tags/location, derived model with name0 serialized as name).

Generated by Agentic Triage

[live1206]

One more MTG gap related to this issue: TypeFactory currently caches model/type creation by InputModelType / InputType object identity. That means an equivalent InputModelType instance with the same CrossLanguageDefinitionId can bypass the custom provider returned for the canonical model.

This shows up in Azure/azure-sdk-for-net#56634 for management-plane resource data models. MPG returns a custom ResourceDataModelProvider so a resource data model is declared in the root SDK namespace as FooData, but another equivalent model instance can still be resolved through the default model path and produce stale references such as Azure.ResourceManager.X.Models.FooData.

I verified locally that canonicalizing named InputModelTypes by non-empty, non-duplicate CrossLanguageDefinitionId before consulting the MTG model/type caches and before calling CreateModelCore fixes the regression without requiring MPG to walk generated providers and rewrite stale CSharpType references.

Suggested MTG behavior:

• For InputModelType with a non-empty, unique CrossLanguageDefinitionId, use the canonical model from InputNamespace.Models before CreateModel, CreateCSharpType, and related cache lookup.
• Fall back to object identity when the ID is missing or duplicated.
• This lets generators return a specialized provider once for the canonical model and have equivalent model references resolve to that provider's CSharpType consistently.