Should Microsoft.Extensions.Http.Polly be deprecated in favour of Microsoft.Extensions.Http.Resilience?

[IanKemp]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

Microsoft.Extensions.Http.Polly references Polly.Extensions.Http, the latter of which is marked as deprecated and tells you to use Microsoft.Extensions.Http.Resilience, so should Microsoft.Extensions.Http.Polly continue to exist in a non-deprecated form? If so, when should one use Microsoft.Extensions.Http.Polly over Microsoft.Extensions.Http.Resilience?

It is also quite confusing for Microsoft.Extensions.Http.Polly to exist as a v8 package when it doesn't actually reference v8 of Polly.

Related: #55356

Describe the solution you'd like

Guidance on usage of Microsoft.Extensions.Http.Polly going forward.

Additional context

No response

[martincostello]

Speaking as one of the maintainers of Polly:

when should one use Microsoft.Extensions.Http.Polly over Microsoft.Extensions.Http.Resilience?

Only for backwards compatibility - you'll get the best performance with Polly v8 and the Polly.Core functionality that Microsoft.Extensions.Http.Resilience is built on top of. This is non-zero effort to do as the APIs are quite different, so the older approach is still fine to use if you can't make that investment.

For new usage of Polly, I would always recommend using Microsoft.Extensions.Http.Resilience.

It is also quite confusing for Microsoft.Extensions.Http.Polly to exist as a v8 package when it doesn't actually reference v8 of Polly.

This is just the coincidence that Polly v8 and ASP.NET Core 8 were released around the same time - the version numbers matching is unintentional. Microsoft.Extensions.Http.Polly is compatible with Polly v8, but we didn't push to get the version here updated as it wouldn't have brought any noticeable improvements and would have been very last-minute before shipping as we needed to release before .NET 8 so that the resilience libraries could depend on a stable version of Polly.

[amcasey]

Possibly a question for @RussKie?

[RussKie]

I don't think I can add anything to what @martincostello said earlier.

From a consumer standpoint I can totally see the confusion - it took me several minutes to figure out which package belongs to whom as the names are too similar.

If Microsoft.Extensions.Http.Resilience is a strategic replacement for Microsoft.Extensions.Http.Polly, and the latter is only kept for backwards compatibility, then perhaps it's worth considering marking Microsoft.Extensions.Http.Polly as obsolete, updating its readme and providing a guidance on how to migrate to Microsoft.Extensions.Http.Resilience.

@captainsafia @halter73 thoughts?

[captainsafia]

If Microsoft.Extensions.Http.Resilience is a strategic replacement for Microsoft.Extensions.Http.Polly, and the latter is only kept for backwards compatibility, then perhaps it's worth considering marking Microsoft.Extensions.Http.Polly as obsolete, updating its readme and providing a guidance on how to migrate to Microsoft.Extensions.Http.Resilience.

As I recall, obsoleting Microsoft.Extensions.Http.Polly was the plan back at the end of .NET 8. We didn't end up pursuing that however because there was still a vestigial reference to APIs in Microsoft.Extensions.Http.Polly from Microsoft.Extensions.Http.Resilience. We decide to hold off on the deprecation until Microsoft.Extensions.Http.Resilience no longer took any dependency on Microsoft.Extensions.Http.Polly.

It looks like Microsoft.Extensions.Htt.Polly was removed as a dependency back in September via dotnet/extensions#4475. Based on that, I see no reason not to move forward with obsoletion.

[HamsterExAstris]

Microsoft.Extensions.Http.Resilience is only supported on .NET Core, not on .NET Framework like Microsoft.Extensions.Http.Polly. I don't think the latter should be deprecated until the former officially supports .NET Framework too.

1>C:\Users\USERNAME\.nuget\packages\microsoft.extensions.telemetry.abstractions\9.2.0\buildTransitive\net462\Microsoft.Extensions.Telemetry.Abstractions.targets(10,5): warning : Microsoft.Extensions.Telemetry.Abstractions 9.2.0 doesn't support net48 and has not been tested with it. Consider upgrading your TargetFramework to net8.0 or later. You may also set <SuppressTfmSupportBuildWarnings>true</SuppressTfmSupportBuildWarnings> in the project file to ignore this warning and attempt to run in this unsupported configuration at your own risk.
1>C:\Users\USERNAME\.nuget\packages\microsoft.extensions.dependencyinjection.autoactivation\9.2.0\buildTransitive\net462\Microsoft.Extensions.DependencyInjection.AutoActivation.targets(5,5): warning : Microsoft.Extensions.DependencyInjection.AutoActivation 9.2.0 doesn't support net48 and has not been tested with it. Consider upgrading your TargetFramework to net8.0 or later. You may also set <SuppressTfmSupportBuildWarnings>true</SuppressTfmSupportBuildWarnings> in the project file to ignore this warning and attempt to run in this unsupported configuration at your own risk.
1>C:\Users\USERNAME\.nuget\packages\microsoft.extensions.ambientmetadata.application\9.2.0\buildTransitive\net462\Microsoft.Extensions.AmbientMetadata.Application.targets(5,5): warning : Microsoft.Extensions.AmbientMetadata.Application 9.2.0 doesn't support net48 and has not been tested with it. Consider upgrading your TargetFramework to net8.0 or later. You may also set <SuppressTfmSupportBuildWarnings>true</SuppressTfmSupportBuildWarnings> in the project file to ignore this warning and attempt to run in this unsupported configuration at your own risk.
1>C:\Users\USERNAME\.nuget\packages\microsoft.extensions.telemetry\9.2.0\buildTransitive\net462\Microsoft.Extensions.Telemetry.targets(5,5): warning : Microsoft.Extensions.Telemetry 9.2.0 doesn't support net48 and has not been tested with it. Consider upgrading your TargetFramework to net8.0 or later. You may also set <SuppressTfmSupportBuildWarnings>true</SuppressTfmSupportBuildWarnings> in the project file to ignore this warning and attempt to run in this unsupported configuration at your own risk.
1>C:\Users\USERNAME\.nuget\packages\microsoft.extensions.diagnostics.exceptionsummarization\9.2.0\buildTransitive\net462\Microsoft.Extensions.Diagnostics.ExceptionSummarization.targets(5,5): warning : Microsoft.Extensions.Diagnostics.ExceptionSummarization 9.2.0 doesn't support net48 and has not been tested with it. Consider upgrading your TargetFramework to net8.0 or later. You may also set <SuppressTfmSupportBuildWarnings>true</SuppressTfmSupportBuildWarnings> in the project file to ignore this warning and attempt to run in this unsupported configuration at your own risk.
1>C:\Users\USERNAME\.nuget\packages\microsoft.extensions.resilience\9.2.0\buildTransitive\net462\Microsoft.Extensions.Resilience.targets(5,5): warning : Microsoft.Extensions.Resilience 9.2.0 doesn't support net48 and has not been tested with it. Consider upgrading your TargetFramework to net8.0 or later. You may also set <SuppressTfmSupportBuildWarnings>true</SuppressTfmSupportBuildWarnings> in the project file to ignore this warning and attempt to run in this unsupported configuration at your own risk.
1>C:\Users\USERNAME\.nuget\packages\microsoft.extensions.http.diagnostics\9.2.0\buildTransitive\net462\Microsoft.Extensions.Http.Diagnostics.targets(5,5): warning : Microsoft.Extensions.Http.Diagnostics 9.2.0 doesn't support net48 and has not been tested with it. Consider upgrading your TargetFramework to net8.0 or later. You may also set <SuppressTfmSupportBuildWarnings>true</SuppressTfmSupportBuildWarnings> in the project file to ignore this warning and attempt to run in this unsupported configuration at your own risk.
1>C:\Users\USERNAME\.nuget\packages\microsoft.extensions.http.resilience\9.2.0\buildTransitive\net462\Microsoft.Extensions.Http.Resilience.targets(7,5): warning : Microsoft.Extensions.Http.Resilience 9.2.0 doesn't support net48 and has not been tested with it. Consider upgrading your TargetFramework to net8.0 or later. You may also set <SuppressTfmSupportBuildWarnings>true</SuppressTfmSupportBuildWarnings> in the project file to ignore this warning and attempt to run in this unsupported configuration at your own risk.

[captainsafia]

cc: @joperezr Thoughts on whether or not we should deprecate this?

[joperezr]

I agree that we should move on with the deprecation to help bring clarity for consumers. If we are doing this for 10, I do think that we should cover some of the things that have been brought up here like making sure we have docs on how to move from the old one to the new one, as well as consider adding netstandard2.0 support to the one in extensions (which we already have an issue tracking this)