Consider creating a signed version of Brighter

[iancooper]

The Polly drama has opened up the issue that because we are not signed we can run into difficulty in environments that need signed assemblies. Whilst unsigned can depend on signed, signed needs signed. As a result we may choose to sign Brighter.

We would adopt the Newtonsoft strategy:

• DLLs are strong-named
• semver the nuget packages
• assemblies within the package have major version only for "Strong name" and "Full Name"
• assemblies within the package have major.minor.patch for "AssemblyFileVersion" and "AssemblyInformationalVersion"

We could sign Brighter and ServiceActivator that only depend on strong-named packages. The transports might not be strong-named if we cannot find a strong-named version of the lib that we depend on, which would become caveat emptor.

We would include the key in the repo, without password protection to enable local builds.

Whilst we don't like strong-naming we may not be able to fight against it.

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[holytshirt]

Referencing the Polly issue
App-vNext/Polly#442

[holytshirt]

Pulled in polly, all working no need to sign brighter

[iancooper]

I a reopening this issue, as guidance from MS is now to sign.

https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/strong-naming#create-strong-named-net-libraries

We have to play as part of the ecosystem. It is possible that someone is going to refuse to play with us because we don't strong name. However, we are a framework, not a library so we are more top-level and folks don't depend on us. That might mean we choose not too. But, there is no real advantage is the entire ecosystem moves to strong naming.

[holytshirt]

fix in v8.0.*