[http-client-csharp] Acronym parameter compatibility emits undeclared deserialization variables

[live1206]

Describe the bug

The C# generator emits undeclared local variables and substitutes default for constructor arguments when deserializing some models whose property names begin with an acronym such as VMware.

This is a regression between:

• Microsoft.TypeSpec.Generator.ClientModel 1.0.0-alpha.20260817.7 (commit 1a7f2f4d05e819a8312528e8d207af2f90597d63)
• Microsoft.TypeSpec.Generator.ClientModel 1.0.0-alpha.20260818.17 (commit a849fcfc965b6dc0cb8dffcb32132e71655a6b4a)

The affected range contains #11714 and its follow-up #11719. In particular, #11714 changed PropertyProvider.AsVariableExpression to reuse AsParameter, while #11719 changed normalization of newly generated property-derived parameters. The combination appears to make deserialization use the normalized/back-compat parameter expression without producing a corresponding local declaration or constructor argument.

Reproduction

Full Azure SDK for .NET regeneration:

• Generator bump: Bump http-client-csharp version for mgmt Azure/azure-sdk-for-net#62248
• Full regeneration: Update azure-typespec/http-client-csharp-mgmt version to prerelease 1.0.0-alpha.20260819.2 Azure/azure-sdk-for-net#62250
• Azure.Generator: 1.0.0-alpha.20260818.5
• Microsoft.TypeSpec.Generator.ClientModel: 1.0.0-alpha.20260818.17

Two affected generated models are:

• InMageRcmFabricCreationContent
• VMwareCbtEnableMigrationContent

For InMageRcmFabricCreationContent, the previous generator emitted:

ResourceIdentifier vMwareSiteId = default;
// ...
vMwareSiteId = new ResourceIdentifier(prop.Value.GetString());
// ...
return new InMageRcmFabricCreationContent(
    instanceType,
    additionalBinaryDataProperties,
    vMwareSiteId,
    physicalSiteId,
    sourceAgentIdentity);

The new generator emits:

// No vmwareSiteId declaration
// ...
vmwareSiteId = new ResourceIdentifier(prop.Value.GetString());
// ...
return new InMageRcmFabricCreationContent(
    instanceType,
    additionalBinaryDataProperties,
    default,
    physicalSiteId,
    sourceAgentIdentity);

VMwareCbtEnableMigrationContent has the equivalent change from the declared vMwareMachineId local to an undeclared vmwareMachineId, followed by default in the constructor call.

The full repository build fails with:

error CS0103: The name 'vmwareMachineId' does not exist in the current context
error CS0103: The name 'vmwareSiteId' does not exist in the current context

Relevant generated diffs:

• https://github.com/Azure/azure-sdk-for-net/pull/62250/files#diff-b401c5c3613b953cc1efcdc597ee2873f754cf8e54cae190ad88eb7b6217fa83
• https://github.com/Azure/azure-sdk-for-net/pull/62250/files#diff-e1caf1df49f06b08fb951235aae0b1ec881b2b5be107b5661fb3d42f8e922e69

Expected behavior

The deserializer should:

1. Declare exactly one local for each deserialized property.
2. Assign the JSON value to that local.
3. Pass that local to the model constructor.
4. Keep generated local/parameter naming internally consistent regardless of acronym normalization or last-contract parameter spelling.

It must not emit an undeclared assignment or replace a successfully deserialized required value with default.

Impact

The generated SDK does not compile. Independently of the compile error, the generated default constructor argument would discard the deserialized resource identifier.

The management generator's own test suite does not currently cover the combination of acronym-prefixed properties, last-contract constructor compatibility, and model deserialization, so its CI passed while the full Azure SDK regeneration failed.

Related issues: #11696, #11707.

- by copilot

[github-actions]

🎯 Issue Triage

A regression introduced by #11714 and #11719 causes the C# generator to emit undeclared local variables and substitute default for constructor arguments when deserializing models with acronym-prefixed properties (e.g., VMware), breaking the generated SDK's compilation.

Category: Bug
Area: emitter:client:csharp

🔍 Analysis

• Root cause: PropertyProvider.AsVariableExpression was changed in Fix C# synthesized acronym parameter compatibility #11714 to reuse AsParameter. Then Normalize new IPv4 parameter names #11719 changed normalization of property-derived parameters. The combination causes the deserialization code to use the normalized parameter name (e.g., vmwareSiteId) for the assignment target while the local variable declaration uses the original casing (vMwareSiteId), resulting in no matching declaration. The constructor call then falls back to default instead of the local.
• Affected components: http-client-csharp — PropertyProvider, deserialization code generation, parameter naming/normalization.
• Impact: Generated SDKs fail to compile (CS0103). Even without the compile error, the deserialized value is silently discarded via default.
• Test gap: The management generator's CI passed because it lacks test coverage for acronym-prefixed properties combined with last-contract constructor compatibility and model deserialization.
• Related issues: C# acronym normalization ignores management SDK ApiCompat contracts #11696, [http-client-csharp] Acronym normalization indirectly renames public model-factory parameters #11707, Fix C# synthesized acronym parameter compatibility #11714, Normalize new IPv4 parameter names #11719.

📝 Suggested next steps

• Fix PropertyProvider to ensure the local variable declaration name and assignment target name are always consistent, regardless of acronym normalization.
• Ensure the constructor argument always references the declared local (not default) when deserialization succeeds.
• Add test coverage for models with acronym-prefixed properties (VMware, VM, etc.) in the deserialization path with last-contract constructor compatibility.

Generated by Agentic Triage

[JoshLove-msft]

I reproduced the reported model shape directly in Microsoft.TypeSpec.Generator.ClientModel using a current vmwareSiteId property plus a last-contract constructor parameter named vMwareSiteId.

The unbranded deserializer output is internally consistent and valid:

string vmwareSiteId = default;
// ...
vmwareSiteId = prop.Value.GetString();
// ...
return new TestModel(vmwareSiteId, additionalBinaryDataProperties);

The undeclared assignment and default constructor argument are introduced later by the Azure management emitter's ModelFactoryBackwardCompatHelper.FixConstructorCalls. Its name-based reconstruction did not match vmwareSiteId with the historical vMwareSiteId, replaced the constructor slot with default, and removed the local declaration as unused.

The actual fix is Azure/azure-sdk-for-net#62240. It now prefers exact ordinal argument matches and falls back to a casing-insensitive match only when unambiguous; 271/271 management generator tests pass, including casing-only and case-collision regressions.

This issue does not reproduce in the unbranded emitter at current main (a849fcfc9). --generated by Copilot