Strong-named binaries

[davidni]

Expected Behavior / New Feature

Ocelot binary (ocelot.dll) is not strong-named

Actual Behavior / Motivation for New Feautre

Ocelot cannot currently be consumed from strong-named projects. Projects that are strong-named must reference only strong-named dependencies, so Ocelot would have to be strong-named too,

Specifications

• Version: 7.0.5

[davidni]

Note that in order to do this, the first step would be to produce strong-named versions of Ocelot dependencies. I see 5 problematic ones:

• Steeltoe.Common
• Rafty
• IdentityServer4
• IdentityServer4.AccessTokenValidation
• Pivotal.Discovery.ClientCore

Rafty should be easy to tackle. Not sure about the others.

[TomPallister]

@davidni this is something we could look at one day but not anytime soon given the dependencies.

[raman-m]

Zero benefit, in my opinion!

@davidni Show us at least one user /contributor who will make their web app assemblies strong-named? Maybe Microsoft will re-use Ocelot.dll in products as strong-named assembly? 🤣

But from other side, Ocelot is distributed through public channels like NuGet, so we need to make Ocelot.dll strong-named. Well... It is dilemma!