Remove strong named assembly version of Polly for non-SN version

[iancooper]

It is great that this project has decided to use Polly over writing it's own Retry and Circuit Breaker implementations. But, it should be remembered that a lot of other projects have been using Polly for some time, and ship with it as a dependency.

Those projects tend not to use signed assemblies, which are viral and unnecessary in a post-GAC age HttpClientFactory ships with a signed version of Polly and thus breaks all those projects. It is a destructive bullet fired right into the existing ecosystem as a result.

See: BrighterCommand/Brighter#286

At its heart this exposes the very issue with signed assemblies, their virality. They are an infection that spreads throughout the ecosystem.

Please remove the dependency of this project on a signed version of Polly so that you can continue to be compatible with all the other projects in the ecosystem that already use Polly.

[martincostello]

ASP.NET Core needs to ship with strong-naming, so they'd have to remove it entirely 😞

[iancooper]

But why are they shipping Polly, not just referencing the existing package?

[martincostello]

Signed packages can't reference unsigned packages.

[iancooper]

Let's just break the ecosystem then. Because everyone who is currently using Polly is now broken. That is a catastrophic change, not a positive step forward for the community

[martincostello]

I guess they were trying to let people get the benefits of Polly for free out-of-the-box without having to know the implementation details.

AFAIK there's only one way to resolve this issue, which is to remove this functionality completely. Polly comes in two flavours - using the signed version breaks the non-signed consumers (who can maybe fix it by switching to signed instead, where it's just a preference/dislike of strong-naming, rather than a technical constraint), using the unsigned version breaks the signed consumers with no fix path as signed packages can't reference unsigned packages.

[rvanmaanen]

I guess they were trying to let people get the benefits of Polly for free out-of-the-box without having to know the implementation details.

That's great and I thinkt the integration with Polly is awesome, but it kinda sucks for everyone not using signed packages. So even if Ian fixes this, then I have to head over to yet someone else to ask them to use his signed version and go through this again.. Don't know of any other solution either though..

[iancooper]

I think the issue could be that Polly-Signed is actually strong named. Do MS require strong named?

[martincostello]

ASP.NET Core needs to ship with strong-naming...

Otherwise anyone who needs to strong-name their code couldn't consume .NET Core at all.

[iancooper]

But this is just painful as it is a breaking change for all existing users of Polly. It's destructive to the downstream ecosystem

[martincostello]

Like I said, the only resolution to this issue that isn't doing nothing is to remove the Polly-related code completely.

[iancooper]

OK, but this is damaging to the existing ecosystem as is, because it breaks everyone else

[iancooper]

BTW, the switch to strong naming is not simply preference, as it's viral. In order to strong name, I have to use only strong-named packages and any consumer has to now use strong naming. If those packages do not provide a strong named version, then you can no longer use them. And the chain is the problem, it only takes one weak link and you are done. It's not a trivial change and it ripples through the ecosystem. So it is a constraint.

The issue here is the problematic need of aspnet to strong-name, which is placing burdens on the ecosystem.

[martincostello]

The root of the problem is that strong-naming ever existed, but as that's a fait accompli, library developers are stuck between a rock and a hard-place of whether to use unsigned packages and completely preclude their use from developers who need strong-naming (for whatever reason, I'm making no assertions here about why someone would choose/need to do that and whether they should or not), or providing a strong-named package that requires other packages to do the same to preserve the dependency chain (or providing one of each).

The former is a hard-block, signed can't use unsigned, where as unsigned can use signed. In a world of compromises, providing a signed package that (dependency chains aside) works for both use cases is the choice that makes the most sense.

Personally, I have no strong opinions of strong-naming in of itself, but it's a lot less headache as a library developer (when you have no dependencies of your own beyond the Framework/SDK) to just provide one package and sign the assemblies in it.

I'm sure a similar debate would have happened for Newtonsoft.Json at some point in time (unless it's always been strong-named), given that that's a dependency you can use anywhere as well as being a dependency of ASP.NET Core itself.

[iancooper]

It's not as simple as that. Strong naming becomes viral because now, all my dependencies must be strong-named. So even if it is only my package that depends on Polly, all the packages in my chain must now support strong naming. If they don't then I have two choices (a) stop using Polly (b) fork and rename Polly to use my own version instead. The chain of dependencies is the issue.

This is the heart of the failure of strong-naming, that you couple everyone into the decision, and coupling of that kind makes it hard to release. Strong naming also introduces harsher versioning constraints to support side-by-side loading. which forces assembly binding redirection (and woe betide platforms that don't support that). In fact lack of support for assembly binding redirection is why most people stopped using strong naming. Most developers don't understand binding redirection, or why they would need it.

Indeed if Polly intends to version rapidly, then strong naming is highly problematic.

Jeremy Miller has a reasonable account of experiences here: https://jeremydmiller.com/2014/04/28/fubumvc-lessons-learned-strong-naming-woes-and-workarounds/

And for what? The GAC? In a post container and 12 factor app world, no one should be installing in the GAC because every container should hold one app and one alone. For security? Most snk files in GitHub repos are not password protected so as to make it easy to build local versions.

Strong naming is a tax on the OSS ecosystem with no benefit.

Our choices are (1) Fork Polly to 'Parrot' or the like so that we can avoid a clash (2) Break Polly library support out of Brighter, and into a plug in assembly that abstracts our dependency on Polly and just sign that [Note that MS could do this if they shipped their extensions without badging them as MS] (3) ILMerge Polly into Brighter to avoid dependencies.

But anyone who has used Polly in their library will now have to review their entire dependency chain, ensure that they can obtain a strong named version, and sign there version. In turn, anyone who uses that library will have to make the same choices.

This is dropping a large rock into the pond - there will be a lot of outward ripples