Description
Generated Azure management resource and resource-collection methods do not always restore parameter names from the previous GA contract.
This is source-breaking for callers that use named arguments and is reported by ApiCompat as CP0017.
This is similar to:
However, this case affects generated resource/collection operation methods and the forwarding methods generated on parent resources.
Reproduction
In Azure/azure-sdk-for-net, build:
dotnet build .\sdk\redis\Azure.ResourceManager.Redis\src\Azure.ResourceManager.Redis.csproj --nologo
The build fails with 36 CP0017 errors across netstandard2.0, net8.0, and net10.0.
Representative errors:
Parameter name on member 'Azure.ResourceManager.Redis.RedisResource.GetRedisPatchScheduleAsync(RedisPatchScheduleDefaultName, CancellationToken)' changed from 'defaultName' to 'default'.
Parameter name on member 'Azure.ResourceManager.Redis.RedisPatchScheduleCollection.CreateOrUpdateAsync(WaitUntil, RedisPatchScheduleDefaultName, RedisPatchScheduleData, CancellationToken)' changed from 'defaultName' to 'default'.
Parameter name on member 'Azure.ResourceManager.Redis.RedisPatchScheduleCollection.GetIfExists(RedisPatchScheduleDefaultName, CancellationToken)' changed from 'defaultName' to 'default'.
Affected collection methods include CreateOrUpdate[Async], Get[Async], Exists[Async], and GetIfExists[Async]. The parent RedisResource.GetRedisPatchSchedule[Async] forwarding methods are also affected.
The newly generated signatures use:
RedisPatchScheduleDefaultName @default
while the previous GA contract used:
RedisPatchScheduleDefaultName defaultName
Other generated surfaces, such as RedisPatchScheduleResource.CreateResourceIdentifier and ArmRedisModelFactory.RedisPatchScheduleData, preserve defaultName, which isolates the gap to resource/collection operation methods.
Root-cause theory
The shared C# generator has general method parameter-name restoration in BackCompatHelper.RestorePreviousParameterNames, invoked by TypeProvider.BuildMethodsForBackCompatibility.
The management providers also call the base implementation:
ResourceCollectionClientProvider.BuildMethodsForBackCompatibilityResourceClientProvider.BuildMethodsForBackCompatibility
Despite that, the previous name is not restored for these methods. The affected methods are synthesized management wrappers rather than the original convenience methods:
ResourceOperationMethodProvider builds collection/resource signatures from convenience-method parameters through OperationMethodParameterHelper.GetOperationMethodParameters.ResourceClientProvider.BuildGetChildResourceMethods creates parent-resource forwarding methods by copying the generated collection method signature.- Because the synthesized resource/collection parameter is not matched to the corresponding previous-contract parameter, the shared restoration leaves
default unchanged.
- The forwarding methods then propagate the same unrestored parameter name.
The likely missing case is therefore parameter-name restoration for synthesized resource/collection operation methods where input-parameter provenance and/or positional signature matching does not resolve to the previous contract. This should be handled by the base generator rather than with Redis-specific customization.
The relevant general method back-compat work is #10988 and #11491, but this resource/collection shape is still not covered.
Expected behavior
When a generated public/protected resource or collection method has the same method name and positional C# parameter types as the previous contract, restore the previous parameter names, including C# keyword stabilization such as default -> defaultName.
Forwarding resource methods should inherit the restored collection parameter names.
Suggested tests
- A
ResourceCollectionClientProvider operation with a path parameter whose current name is a C# keyword and whose previous name was keyword-suffixed.
CreateOrUpdate, Get, Exists, and GetIfExists sync/async methods.- The corresponding parent-resource forwarding
Get<Resource>[Async] methods.
- Verify that the restored parameter provider remains connected to XML docs and method-body arguments.
Description
Generated Azure management resource and resource-collection methods do not always restore parameter names from the previous GA contract.
This is source-breaking for callers that use named arguments and is reported by ApiCompat as
CP0017.This is similar to:
However, this case affects generated resource/collection operation methods and the forwarding methods generated on parent resources.
Reproduction
In Azure/azure-sdk-for-net, build:
dotnet build .\sdk\redis\Azure.ResourceManager.Redis\src\Azure.ResourceManager.Redis.csproj --nologoThe build fails with 36
CP0017errors acrossnetstandard2.0,net8.0, andnet10.0.Representative errors:
Affected collection methods include
CreateOrUpdate[Async],Get[Async],Exists[Async], andGetIfExists[Async]. The parentRedisResource.GetRedisPatchSchedule[Async]forwarding methods are also affected.The newly generated signatures use:
while the previous GA contract used:
Other generated surfaces, such as
RedisPatchScheduleResource.CreateResourceIdentifierandArmRedisModelFactory.RedisPatchScheduleData, preservedefaultName, which isolates the gap to resource/collection operation methods.Root-cause theory
The shared C# generator has general method parameter-name restoration in
BackCompatHelper.RestorePreviousParameterNames, invoked byTypeProvider.BuildMethodsForBackCompatibility.The management providers also call the base implementation:
ResourceCollectionClientProvider.BuildMethodsForBackCompatibilityResourceClientProvider.BuildMethodsForBackCompatibilityDespite that, the previous name is not restored for these methods. The affected methods are synthesized management wrappers rather than the original convenience methods:
ResourceOperationMethodProviderbuilds collection/resource signatures from convenience-method parameters throughOperationMethodParameterHelper.GetOperationMethodParameters.ResourceClientProvider.BuildGetChildResourceMethodscreates parent-resource forwarding methods by copying the generated collection method signature.defaultunchanged.The likely missing case is therefore parameter-name restoration for synthesized resource/collection operation methods where input-parameter provenance and/or positional signature matching does not resolve to the previous contract. This should be handled by the base generator rather than with Redis-specific customization.
The relevant general method back-compat work is #10988 and #11491, but this resource/collection shape is still not covered.
Expected behavior
When a generated public/protected resource or collection method has the same method name and positional C# parameter types as the previous contract, restore the previous parameter names, including C# keyword stabilization such as
default->defaultName.Forwarding resource methods should inherit the restored collection parameter names.
Suggested tests
ResourceCollectionClientProvideroperation with a path parameter whose current name is a C# keyword and whose previous name was keyword-suffixed.CreateOrUpdate,Get,Exists, andGetIfExistssync/async methods.Get<Resource>[Async]methods.