Strong naming

[nathan-alden-sr]

According to Microsoft, published .NET libraries should be strong-named. Stylet is not.

I'll submit a PR with the small amount of changes necessary to strong name the library.

[canton7]

This popped up a little while back in another repo of mine. Link.

At that point, I had 4 questions:

• Strong naming an assembly messes with binding redirects in NuGet. The workaround seems to be to freeze the assembly version. People have referred to this as being a breaking change, requiring a separate NuGet package, but I'm not yet sure why.
• The 'dotnet' tooling doesn't support signing assembles. Apparently you can strong name assemblies without signing them, but I'm not sure of the distinction. Reference.
• Delay sign or not? Public sign or not?
• Commit the private key or not? Some projects seem to be committing it.

In fairness the dotnet tooling has probably improved (I haven't checked), but I still don't have a firm grasp on the others, and no one advocating strong naming had proposed any answers. If you've got input I'd welcome it!

As it stands, I'm not clear on the consequences particularly around binding redirects, so unless anyone is actively requesting strong naming (rather than it just being "a good idea", I'm reluctant given the potential for badly-understood and unforeseen future consequences.

[nathan-alden-sr]

Strong naming an assembly messes with binding redirects in NuGet. The workaround seems to be to freeze the assembly version. People have referred to this as being a breaking change, requiring a separate NuGet package, but I'm not yet sure why.

I think it's reasonable to not want to change this especially for .NET Framework, given how common it is to use binding redirects with Framework. Perhaps you could mitigate the concerns by building a net6.0 TFM that is strong-named and leaving existing TFMs untouched.

The 'dotnet' tooling doesn't support signing assembles. Apparently you can strong name assemblies without signing them, but I'm not sure of the distinction. Reference.

I am strong-naming my own .NET 5 code with the dotnet toolchain (it just calls MSBuild). Much of the way I do this is based on Tanner Gooding's TerraFX.Interop.Windows library. Considering he is a Microsoft employee and owner of System.Numerics, I trust this is something he's thought about. I personally have not experienced any issues with .NET 5 and strong naming support. In fact, before submitting this PR I built your solution using dotnet build with both configurations.

Delay sign or not? Public sign or not?

I think this has to do with cryptographic signing of the PE binaries and not strong naming. Strong naming is completely separate from signing PE binaries. EDIT: Ah, I remember now. The concern here is if you cryptographically sign the PE binary, then you can't strong name it after because it changes the binary (I think?)

Commit the private key or not? Some projects seem to be committing it.

I've always committed the .snk to source control. Tanner seems comfortable doing that. It's possible there are nuances here I'm not aware of.

I'll try to get someone to comment here that is more knowledgeable about the intricacies than I am.

[tannergooding]

Strong naming an assembly messes with binding redirects in NuGet. The workaround seems to be to freeze the assembly version. People have referred to this as being a breaking change, requiring a separate NuGet package, but I'm not yet sure why.

This is answered by 2.1 of https://github.com/dotnet/runtime/blob/main/docs/project/strong-name-signing.md#2-i-really-really-need-to-strong-name-what-kinds-of-issues-will-i-run-into

Binding Policy. When developers talk about strong-names, they are usually conflating it with the strict binding policy of the .NET Framework that kicks in when you strong-name. This binding policy is problematic because it forces, by default, an exact match between reference and version, and requires developers to author complex binding redirects when they don't. In recent versions of Visual Studio, however, we've added Automatic Binding Redirection as an attempt to reduce pain of this policy on developers. On top of this, all newer platforms, including Silverlight, WinRT-based platforms (Phone and Store), .NET Native and ASP.NET 5 this policy has been loosened, allowing later versions of an assembly to satisfy earlier references, thereby completely removing the need to ever write binding redirects on those platforms.

---

The 'dotnet' tooling doesn't support signing assembles. Apparently you can strong name assemblies without signing them, but I'm not sure of the distinction. Reference.

This sounds like you're referring to Authenticode Signing, which is done for security. This is different from strong name signing which is exclusively for Identity (differentiating two assemblies with the same name).

Delay sign or not? Public sign or not?
Commit the private key or not? Some projects seem to be committing it.

As Nathan indicated the modern recommendation (https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/strong-naming) is to check your entire key into source control. DelaySign and PublicSign exist to cover scenarios where the entire key is not available or where you need to, such as due to prior support for partial-trust scenarios, hide the private key from public availability.

• DelaySign is the older approach for handling only having the public key available. It requires you to finish signing with the private half for it to be considered valid.
• PublicSign is the modern alternative and allows an assembly to be signed with only the public half of the key. The assembly is still usable without completing the second half of the signing process.
  • https://github.com/dotnet/runtime/blob/main/docs/project/public-signing.md