Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

[DONE; update documentation] publish Polly v6.0.0 as strong-named only

See original GitHub issue

CONSIDER publishing Polly v6.0.0 as strong-named only

Background

ASP.NET Core 2.1 is moving to consume Polly for HttpClient instances created through HttpClientFactory. This will allow the easy application of Polly resilience strategies to outbound calls through HttpClient.

This will significantly increase consumption of Polly’s strong-named package (currently labelled Polly-Signed). That however will create conflicts for packages or projects that currently consume non-strong-named Polly: example; longer discussion.

There is no easy answer to this problem, as attested by discussion on numerous projects: octokit and the many projects that reference that issue.

Options:

~Be purely non-strong-named~: project cannot then be consumed in environments or by upstream packages mandating strong-naming; not an option for Polly due to ASP.NET Core.
Offer both strong-named and not (as Polly currently): but creates conflicts where a project ends up transiently referencing both.

Or:

Publish only strong-named

Some consensus among high-consumption projects now is around this, the NewtonSoft.Json strategy, as the least of all evils. @jeremyskinner of FluentValidation sums it up well here as does @sharwell elsewhere. I summarise also here.

TL;DR Switching to release Polly as strong-named only would be a one-time hit breaking change for consumers of Polly. But thereafter, having only the strong-named version of Polly in the market would prevent/reduce those conflicts (strong-named versus not) going forward.

(edited: for typos)

This is a proposal on which we would appreciate evidence-driven feedback. Particularly any consumption scenarios we may not be aware of. The proposed change is driven by the HttpClientFactory ASP.NET Core integration, which will drive many more Polly users to the strong-named version. ASP.NET Core has prior decision to be strong-named and thus consume strong-named assemblies.