StrongNamed version of the assembly

Is your feature request related to a problem? Please describe. A codebase with a lot of use of InternalsVisibleTo so all assemblies must be signed.

Describe the solution you’d like Either sign the final assembly or have a signed nuget version as some other libs do.

Describe alternatives you’ve considered Is not possible to load a non signed assembly from a signed assembly, at compile time at least…

Additional context

[sebastienros]

Main benefit is that users who have to use a strong named assembly can use yours. https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/strong-naming

Until nobody is using it anymore I’d recommend to ship the package strongly named. It’s as easy as adding the .snk file to the repos and add a tag in the csproj.

[daxian-dbw]

+1 to @sebastienros’ comment.

Afaik there is no benefit of strong naming .NET Core assemblies since the signature isn’t validated or used for assembly binding

@patriksvensson The Spectre.Console package also targets .NETStandard 2.0, which means it’s designed to be useable to a .NET Framework application as well. It’s quite common for a .NET Framework application to be strong named, and thus it makes it unnecessarily hard to use this package for a .NET Framework application.

In .NET Core world, there may not be benefit from the technical perspective, but there is also no harm to have it strong named. And for applications that still have to be strong named (e.g. PowerShell), it would also make it a lot easier to depend on Spectre.Console. So, overall, I think there is benefits to have this assembly strong named. Please re-consider doing this, thanks!