C# acronym normalization ignores management SDK ApiCompat contracts

[live1206]

Describe the bug

The acronym normalization introduced by #11641 renames existing public management SDK types and properties even when their original names are present in the package's ApiCompatVersion contract.

The implementation is intended to normalize only new contract names and preserve names found through FindForTypeInLastContract or LastContractView. In a full Azure SDK for .NET management regeneration, that preservation does not occur consistently.

Reproduction

Regenerate Azure SDK management packages using:

• @typespec/http-client-csharp: 1.0.0-alpha.20260813.5
• Azure.Generator: 1.0.0-alpha.20260813.5
• Full regeneration PR: Failed: Update azure-typespec/http-client-csharp-mgmt version to prerelease 1.0.0-alpha.20260813.3 Azure/azure-sdk-for-net#62087

Examples where the old name is present in the tagged GA API contract but is still renamed:

Package / ApiCompatVersion	Existing contract name	Generated name
Azure.ResourceManager.OracleDatabase / 1.2.1	OracleBaseDbSystemShape	OracleBaseDBSystemShape
Azure.ResourceManager.Network / 1.16.1	VirtualNetworkApplianceIpVersionType	VirtualNetworkApplianceIPVersionType
Azure.ResourceManager.Sql / 1.4.0	SyncMemberDbType	SyncMemberDBType
Azure.ResourceManager.SqlVirtualMachine / 1.1.2	SqlVmOsType	SqlVMOSType
Azure.ResourceManager.PostgreSql / 1.4.2	PostgreSqlMigrationLogicalReplicationOnSourceDb	PostgreSqlMigrationLogicalReplicationOnSourceDB

Machine Learning also renames existing GA properties including PrivateIpAddress, PublicIpAddress, HostIp, OsVhdSizeMB, and IsLatestOsImageVersion.

These changes cause compile failures where custom code or generated compatibility model-factory methods reference the contracted names. They also produce breaking public API changes in packages that otherwise compile.

Expected behavior

If a public type or property exists in the assembly identified by ApiCompatVersion, preserve its existing spelling. Apply acronym normalization only to genuinely new contract members.

Additional context

Names absent from the GA baseline are normalized as expected, so the issue appears specific to last-contract discovery or matching in the management generator integration rather than the normalization rules themselves.

​- by copilot

[live1206]

cc JoshLove-msft

[github-actions]

🎯 Issue Triage

The acronym normalization feature introduced in #11641 is incorrectly renaming existing public types and properties in Azure SDK management packages, even when those names exist in the ApiCompatVersion GA contract baseline. This causes compile failures and breaking API changes.

Category: Bug
Area: emitter:client:csharp

⚠️ No reproduction provided. The issue references an external regeneration PR (Azure/azure-sdk-for-net#62087) rather than a minimal standalone repro.

🔍 Analysis

• Root cause: The FindForTypeInLastContract / LastContractView lookup in the management generator integration does not consistently match existing contract members, so the ApiCompat preservation guard is bypassed and acronym normalization is applied regardless.
• Scope: Affects only management SDK packages with an ApiCompatVersion set; new (non-GA) names are normalized correctly.
• Impact: High — causes compile failures in Azure SDK for .NET packages that have custom code referencing contracted names, and introduces breaking public API changes.
• Affected packages: Azure.ResourceManager.OracleDatabase, Azure.ResourceManager.Network, Azure.ResourceManager.Sql, Azure.ResourceManager.SqlVirtualMachine, Azure.ResourceManager.PostgreSql, Azure Machine Learning (properties).
• Introduced by: [http-client-csharp] Normalize common acronyms in model names #11641

📝 Suggested next steps

• Investigate why FindForTypeInLastContract / LastContractView fails to match types/properties that exist in the ApiCompat assembly (name comparison, case sensitivity, assembly loading).
• Add unit tests covering ApiCompat preservation of existing acronym-cased names in http-client-csharp.
• Consider a short-term mitigation to unblock the Azure SDK for .NET regeneration while the root cause is fixed.

Generated by Agentic Triage

[live1206]

The fix is effective for existing GA type names, but the latest full management regeneration shows that existing GA member names are still not consistently preserved.

Reproduction:

• Azure SDK regeneration PR: Failed: Update azure-typespec/http-client-csharp-mgmt version to prerelease 1.0.0-alpha.20260813.3 Azure/azure-sdk-for-net#62087
• Reviewed head: 0f593736b88a60cddba1d53251b53985eb32dbd0
• @typespec/http-client-csharp: 1.0.0-alpha.20260817.7
• Azure.Generator: 1.0.0-alpha.20260817.5
• TypeSpec build recorded by the regeneration: 20260817.2

What is fixed:

• Existing GA type spellings are now preserved, including OracleBaseDbSystemShape, VirtualNetworkApplianceIpVersionType, SyncMemberDbType, SqlVmOsType, and PostgreSqlMigrationLogicalReplicationOnSourceDb.
• Acronym normalization still applies to types that are new relative to the GA contract, as expected.

What remains broken:

Package	Existing GA member missing after regeneration	Generated member
Azure.ResourceManager.Network	ApplicationGatewayBackendSettings.EnableL4ClientIpPreservation	EnableL4ClientIPPreservation
Azure.ResourceManager.Network	RouteData.NextHopIpAddresses	NextHopIPAddresses
Azure.ResourceManager.OracleDatabase	OracleDBSystemPatch.DbSystemUpdateSource	DBSystemUpdateSource
Azure.ResourceManager.ServiceFabricManagedClusters	ServiceFabricManagedNodeTypeData.EnableResilientEphemeralOsDisk	EnableResilientEphemeralOSDisk
Azure.ResourceManager.SqlVirtualMachine	SqlVmData.OsType / SqlVirtualMachineProperties.OsType	OSType
Azure.ResourceManager.PostgreSql	Multiple SourceDb*, TargetDb*, and SetupLogicalReplicationOnSourceDbIfNeeded members	Corresponding DB spellings

Confirmed local failures against the regenerated head:

• Network: 5 distinct CP0002 ApiCompat errors.
• Oracle Database: 2 distinct CP0002 errors.
• PostgreSQL: 19 distinct CP0002 errors.
• Service Fabric Managed Clusters: 2 distinct CP0002 errors.
• Machine Learning: 22 distinct compile errors. Existing custom aliases reference contracted members such as PrivateIpAddress, PublicIpAddress, HostIp, OsVhdSizeMB, and IsLatestOsImageVersion, but those generated properties disappear entirely.
• Managed Network Fabric: 6 distinct compile errors where custom code still references pre-normalized generated types.

The remaining GA failures are mostly flattened/synthesized properties or members surfaced through resource/data/patch wrappers. This suggests last-contract lookup now works for types but still misses some member ownership or generated-artifact mappings. Machine Learning may additionally expose a customization/member-suppression path.

Expected behavior remains: preserve both existing public type names and existing public member names found in ApiCompatVersion; normalize only genuinely new contract symbols.

​- by copilot

[live1206]

Related parameter-compatibility gap: #11707

Although #11641 explicitly excludes parameters, model/property normalization indirectly changes public model-factory parameter names. The latest regeneration contains at least 29 affected methods across 7 packages. Tracking that downstream source-compatibility path separately in the linked issue.

​- by copilot