[http-client-csharp] Date-time normalization breaks MRW deserialization with back-compat constructor parameters

[live1206]

Description

C# date-time property normalization can generate invalid MRW JSON deserialization when the model's constructor parameter name is preserved from the last contract.

This was found while validating Azure/azure-sdk-for-net#62490. That PR updates @typespec/http-client-csharp from 1.0.0-alpha.20260819.14 to 1.0.0-alpha.20260825.9, whose source is commit 210f84c / #11751.

For existing management models, properties such as StartOn and EndOn are normalized to StartsOn and EndsOn, while constructor back-compat preserves the previously generated parameter names startOn and endOn. The MRW deserializer then inconsistently uses the restored constructor parameter names and the renamed property variable expressions.

The resulting generated code can:

1. assign JSON values to undeclared startOn/endOn locals, causing compilation errors; and
2. pass default to the full constructor instead of the parsed values.

Example from AzureReachabilityReportContent.Serialization.cs:

// The startOn/endOn declarations are missing.
foreach (var prop in element.EnumerateObject())
{
    if (prop.NameEquals("startTime"u8))
    {
        startOn = prop.Value.GetDateTimeOffset("O");
        continue;
    }
    if (prop.NameEquals("endTime"u8))
    {
        endOn = prop.Value.GetDateTimeOffset("O");
        continue;
    }
}

return new AzureReachabilityReportContent(
    providerLocation,
    providers ?? new ChangeTrackingList<string>(),
    azureLocations ?? new ChangeTrackingList<AzureLocation>(),
    default,
    default,
    additionalBinaryDataProperties);

The model constructor itself still has the expected slots:

internal AzureReachabilityReportContent(
    AzureReachabilityReportLocation providerLocation,
    IList<string> providers,
    IList<AzureLocation> azureLocations,
    DateTimeOffset startOn,
    DateTimeOffset endOn,
    IDictionary<string, BinaryData> additionalBinaryDataProperties)

Therefore this is not missing input-model information. It is a mismatch between the normalized property identity and the back-compat-restored constructor parameter used by deserialization.

Suspected area

packages/http-client-csharp/generator/Microsoft.TypeSpec.Generator.ClientModel/src/Providers/MrwSerializationTypeDefinition.cs, particularly:

• GetPropertyVariableDeclarations
• BuildDeserializePropertiesStatements
• GetSerializationCtorParameterValues

These paths should use one stable local/parameter identity when a constructor parameter name differs from its associated property's generated name.

A regression test should combine:

• a last-contract constructor parameter named startOn or endOn;
• a current property normalized to StartsOn or EndsOn; and
• MRW JSON deserialization.

The generated deserializer should declare, assign, and pass the same local without replacing the parsed value with default.

The separate question of whether the prior StartOn/EndOn property API should be preserved can be handled independently; regardless of that policy, generated deserialization must compile and retain the parsed values.

Affected generated files

Azure/azure-sdk-for-net#62490 contains the following 11 affected files:

• sdk/avs/Azure.ResourceManager.Avs/src/Generated/Models/VMwareFirewallLicenseProperties.Serialization.cs (endOn)
• sdk/avs/Azure.ResourceManager.Avs/src/Generated/Models/Vcf5License.Serialization.cs (endOn)
• sdk/consumption/Azure.ResourceManager.Consumption/src/Generated/Models/BudgetTimePeriod.Serialization.cs (startOn)
• sdk/costmanagement/Azure.ResourceManager.CostManagement/src/Generated/Models/BenefitUtilizationSummariesContent.Serialization.cs (startOn, endOn)
• sdk/costmanagement/Azure.ResourceManager.CostManagement/src/Generated/Models/BudgetTimePeriod.Serialization.cs (startOn)
• sdk/costmanagement/Azure.ResourceManager.CostManagement/src/Generated/Models/ScheduleProperties.Serialization.cs (startOn, endOn)
• sdk/databox/Azure.ResourceManager.DataBox/src/Generated/Models/ShipmentPickUpContent.Serialization.cs (startOn, endOn)
• sdk/databoxedge/Azure.ResourceManager.DataBoxEdge/src/Generated/Models/PeriodicTimerSourceInfo.Serialization.cs (startOn)
• sdk/dataprotection/Azure.ResourceManager.DataProtectionBackup/src/Generated/Models/DataProtectionBackupJobProperties.Serialization.cs (startOn)
• sdk/dataprotection/Azure.ResourceManager.DataProtectionBackup/src/Generated/Models/RestorableTimeRange.Serialization.cs (startOn, endOn)
• sdk/network/Azure.ResourceManager.Network/src/Generated/Models/AzureReachabilityReportContent.Serialization.cs (startOn, endOn)

Inline examples are also visible in these review threads:

• Update azure-typespec/http-client-csharp-mgmt version to prerelease 1.0.0-alpha.20260826.4 Azure/azure-sdk-for-net#62490 (network)
• Update azure-typespec/http-client-csharp-mgmt version to prerelease 1.0.0-alpha.20260826.4 Azure/azure-sdk-for-net#62490 (cost management)
• Update azure-typespec/http-client-csharp-mgmt version to prerelease 1.0.0-alpha.20260826.4 Azure/azure-sdk-for-net#62490 (AVS firewall license)
• Update azure-typespec/http-client-csharp-mgmt version to prerelease 1.0.0-alpha.20260826.4 Azure/azure-sdk-for-net#62490 (AVS VCF license)

Package/source chain

• Previous management emitter: @azure-typespec/http-client-csharp-mgmt@1.0.0-alpha.20260824.1
  • @typespec/http-client-csharp@1.0.0-alpha.20260819.14
  • source commit 365ec52b50b82cd9e1e037de4c6fcd5de7e32e90
• Failing management emitter: @azure-typespec/http-client-csharp-mgmt@1.0.0-alpha.20260826.4
  • @typespec/http-client-csharp@1.0.0-alpha.20260825.9
  • source commit 210f84c0dee6cfb8226ce95700562c9bf0922822

- by copilot

[github-actions]

🎯 Issue Triage

A regression in @typespec/http-client-csharp@1.0.0-alpha.20260825.9 (introduced by #11751) causes the MRW JSON deserializer to emit invalid C# when date-time properties are normalized (e.g. StartOn → StartsOn) but back-compat constructor parameters retain the old names. The generated code assigns to undeclared locals and passes default instead of parsed values to the constructor.

Category: Bug

Area: emitter:client:csharp

⚠️ No TypeSpec reproduction provided (this is a C# code generation bug; reproduction is in Azure/azure-sdk-for-net#62490).

🔍 Analysis

• Affected component: MrwSerializationTypeDefinition.cs — specifically GetPropertyVariableDeclarations, BuildDeserializePropertiesStatements, and GetSerializationCtorParameterValues.
• Root cause: When a property is renamed by normalization (e.g. StartOn → StartsOn), the property variable name changes, but the back-compat constructor parameter name is still the old form (startOn). The deserializer uses the property variable name for declarations/assignments but the constructor parameter name for passing values, causing a name mismatch — undeclared variable references and default passed instead of parsed values.
• Regression introduced by: Fix C# date-time naming feedback #11751 (date-time normalization in @typespec/http-client-csharp@1.0.0-alpha.20260825.9).
• 11 affected Azure SDK files across avs, consumption, costmanagement, databox, databoxedge, dataprotection, and network packages.

📝 Suggested next steps

• In MrwSerializationTypeDefinition.cs, ensure a single stable local variable name is used across GetPropertyVariableDeclarations, BuildDeserializePropertiesStatements, and GetSerializationCtorParameterValues when a back-compat constructor parameter name differs from the normalized property name.
• Add a regression test: model with last-contract ctor param startOn/endOn, current normalized property StartsOn/EndsOn, and MRW JSON deserialization — verify generated code compiles and passes parsed values (not default).
• Validate fix against Update azure-typespec/http-client-csharp-mgmt version to prerelease 1.0.0-alpha.20260826.4 Azure/azure-sdk-for-net#62490.

Generated by Agentic Triage