[csharp] Generated back-compat overloads in ModelFactory can have non-compiling bodies after large signature changes

[ArcturusZhang]

Bug

When generating C# back-compat overloads in *ModelFactory based on the previously-shipped contract, the generator can emit overloads whose body does not compile — the return expression forwards to the primary overload using arguments that are inconsistent with that primary overload's current parameter list (wrong types, missing/renamed parameters, named-then-positional ordering, etc.).

The signatures themselves are fine; only the bodies are wrong.

Encountered while migrating Azure.ResourceManager.Compute (Swagger → TypeSpec). After regeneration we observed 96 raw / 48 unique compilation errors across 13 distinct factory methods, all in EditorBrowsable(Never) back-compat overloads:

C# error	Count	Example
CS1739 (parameter name doesn't exist)	78	'RestorePointData' has no parameter 'instantAccessDurationMinutes'
CS1503 (cannot convert)	12	cannot convert 'GalleryImageIdentifier' to 'SharedGalleryIdentifier'
CS1744 (positional after named)	6	back-compat call passes reservationType: default then a positional arg

100% of the broken methods carry [EditorBrowsable(EditorBrowsableState.Never)] (i.e. they are auto-generated back-compat shims, not user-authored code).

Reproducer

Azure.ResourceManager.Compute migration branch (will share repo + branch on request).

Representative case — CapacityReservationGroupData:

Primary overload (current generated, valid):

public static CapacityReservationGroupData CapacityReservationGroupData(
    ResourceIdentifier id = default, string name = default, ResourceType resourceType = default, SystemData systemData = default,
    IDictionary<string, string> tags = default, AzureLocation location = default,
    IEnumerable<string> zones = default,
    IEnumerable<SubResource> capacityReservations = default,
    IEnumerable<SubResource> virtualMachinesAssociated = default,
    CapacityReservationGroupInstanceView instanceView = default,
    IEnumerable<WritableSubResource> sharingSubscriptionIds = default,
    CapacityReservationType? reservationType = default)
{ ... }

Back-compat overload emitted by generator (does not compile):

[EditorBrowsable(EditorBrowsableState.Never)]
public static CapacityReservationGroupData CapacityReservationGroupData(
    ResourceIdentifier id, string name, ResourceType resourceType, SystemData systemData,
    IDictionary<string, string> tags, AzureLocation location,
    IEnumerable<string> zones,
    IEnumerable<SubResource> capacityReservations,
    IEnumerable<SubResource> virtualMachinesAssociated,
    CapacityReservationGroupInstanceView instanceView,
    IEnumerable<WritableSubResource> sharingSubscriptionIds)
{
    return CapacityReservationGroupData(
        id, name, resourceType, systemData, tags, location,
        capacityReservations, virtualMachinesAssociated, instanceView,
        reservationType: default,        // CS1744 follows ↓
        sharingSubscriptionIds, zones);  // positional after named
}

Three distinct issues in this single body:

1. zones is passed last; in the primary it's the 7th parameter (after location).
2. reservationType: default is a named argument followed by positional arguments.
3. Several other methods (RestorePointData, ManagedDiskData, CapacityReservationData, SharedGalleryImageData, SnapshotData, AvailabilitySetData/Patch, GalleryData/ImageData, ManagedDiskPatch, CapacityReservationGroupPatch, CapacityReservationPatch) follow the same pattern with renamed/added parameters that the back-compat call site doesn't account for.

Expected

For back-compat overload generation, only emit the overload when the generator can produce a valid forwarding body. If the parameter list of the current primary diverges in a way the generator can't reconcile (renames, type changes, removed parameters), it is more useful to omit the overload and let the SDK author add a hand-written back-compat shim, than to emit code that does not compile.

A "compiles or skips" guarantee on emitted back-compat overloads would dramatically reduce the manual cleanup cost during large migrations.

Workaround used today

Exclude the entire generated ArmComputeModelFactory.cs from compilation via <Compile Remove="..." /> plus [CodeGenSuppress] for the affected overloads, and hand-author replacements in customization code. Both have to be re-evaluated each regen.

[github-actions]

🎯 Issue Triage

The C# client emitter generates back-compat *ModelFactory overloads whose forwarding call bodies are invalid C# — arguments are passed in the wrong order, with wrong names, or with positional args following named args — causing compilation errors. The issue was discovered during the Azure.ResourceManager.Compute Swagger → TypeSpec migration, producing 96 build errors across 13 factory methods.

Category: Bug

Area: emitter:client:csharp

⚠️ No playground reproduction (C# emitter bug; repro requires the full Azure.ResourceManager.Compute migration branch).

🔍 Analysis

• Affected component: Back-compat overload generation logic in the C# emitter's ModelFactory code-gen.
• Root cause: When the primary overload's parameter list changes (new parameters inserted, parameters renamed, or types changed), the generator builds the forwarding body by matching old-contract parameters to new ones incorrectly — resulting in wrong positional order, stale parameter names (CS1739), incompatible types (CS1503), and named-then-positional violations (CS1744).
• Scope: 96 raw / 48 unique errors across 13 factory methods; all under [EditorBrowsable(EditorBrowsableState.Never)] so user code is unaffected at runtime, but SDK packages fail to build.
• Proposed fix direction: Before emitting the back-compat overload body, validate that every forwarded argument can be matched unambiguously to the current primary's parameter list; if not, skip the overload entirely (or emit it as throw new NotImplementedException) so the output always compiles.
• Workaround: <Compile Remove="..."/> + [CodeGenSuppress] on affected overloads, with hand-authored replacements — requires re-evaluation on every regen.

📝 Suggested next steps

• Reproduce locally using the Azure.ResourceManager.Compute migration branch.
• Identify the code-gen path that constructs the forwarding call arguments in the back-compat overload (likely in ModelFactoryWriter or equivalent).
• Add logic to validate argument-to-parameter matching before emitting the body; fall back to skipping the overload if reconciliation fails.
• Add unit/integration tests covering parameter renames, insertions, type changes, and the named-then-positional edge case.

Generated by Agentic Triage