Expected diamond-depndency conflict if multi-versions referenced and third-party component does not update - does not affect HttpClientFactory [ System.TypeLoadException when referencing both Polly 7 and transitive Polly 6 ]

Assuming a solution with the following project/code structure:

PollySeven.MyHttpClient depends on Microsoft.Extensions.Http.Polly (which depends on Polly v6). PollySeven.MyHttpClient uses RetryAsync() extension method to register MyService. PollySeven depends on PollySeven.MyHttpClient and Polly v7. PollySeven uses MyService.

PollySeven

public static void Main(string[] args)
{
    var services = new ServiceCollection();
    services.AddMyServices();

    ServiceProvider provider = services.BuildServiceProvider(true);

    var service = provider.GetRequiredService<MyService>();

    // System.TypeLoadException:
    // 'Could not load type 'Polly.RetrySyntaxAsync' from assembly
    // 'Polly, Version=7.0.0.0, Culture=neutral, PublicKeyToken=c8a3ffc3f8f825cc'.'
}

PollySeven.MyHttpClient

public static IServiceCollection AddMyServices(this IServiceCollection services)
{
    services.AddHttpClient<MyService>()
        .AddTransientHttpErrorPolicy(p => p.RetryAsync());
    return services;
}

When the application runs, I get System.TypeLoadException.

The root cause of this issue might be similar to #611.

Expected behavior: Code executes successfully.

Actual behaviour:

System.TypeLoadException is thrown:

Could not load type 'Polly.RetrySyntaxAsync' from assembly
'Polly, Version=7.0.0.0, Culture=neutral, PublicKeyToken=c8a3ffc3f8f825cc'.

Steps / Code to reproduce the problem:

Example repo: https://github.com/altso/PollySeven

[altso]

Thanks for the clarification @reisenberger. It sounds like there is no way to mitigate this issue in Polly itself. Option (b) worked for me and hopefully will work for others as well.

[altso]

@reisenberger thanks for looking into that. The issue arose in a couple of internal nuget packages and we fixed that by adding an explicit reference to Polly v7 in each of them.

I do not think option (a) is a way to go as you will introduce a breaking change between v7 and v8. I also think option (b) is better but not ideal as it requires additional work from other devs who might not be aware of the issue at all.

A colleague of mine suggested another approach. Let’s call it option ©:

© Bring back all the missing types and methods with the same exact signatures as they had in v6, but provide a bridge to v7 implementations. Something like this:

using System;
using System.ComponentModel;

namespace Polly
{
    [Obsolete]
    [EditorBrowsable(EditorBrowsableState.Never)]
    public static class RetryTResultSyntaxAsync
    {
        [Obsolete]
        [EditorBrowsable(EditorBrowsableState.Never)]
        public static RetryPolicy<TResult> RetryAsync<TResult>(PolicyBuilder<TResult> policyBuilder)
        {
            // The line below actually does not compile as there is no conversion
            // between AsyncRetryPolicy<TResult> and RetryPolicy<TResult>.
            // Call the new api via extension method
            return policyBuilder.RetryAsync(); 
        }
    }
}

Please note:

• types and methods are marked as Obsolete and EditorBrowsable(EditorBrowsableState.Never) to avoid new consumers of this api;
• there is no this keyword in front of PolicyBuilder to avoid compiler confusion around extension methods with the same name.

If not mistaken, that should bring back the binary compatibility between v6 and v7.

Unfortunately, I do not know how to make the code above compile and work properly at the moment - just an idea, but I can take a deeper look if you think it’s worth it. Let me know.

Also, that would be less of an issue if Microsoft.Extensions.Http.Polly is updated to Polly v7. I see the plans to upgrade in v3, but not sure if it’s planned for v2.x as well.