spectre.console
spectre.console copied to clipboard
spectreconsole
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
Hello,
I'm bumping this issue, as we're about to start the work on a new CLI tool, and we'd really like to base it on Spectre.Console.
Is there any way we could contribute to make this happen? If the only blocker is time, then we could push a PR to update your publish pipeline.
@kevingosse Would a tool such as StrongNamer help in this situation?
Afaik there is no benefit of strong naming .NET Core assemblies since the signature isn't validated or used for assembly binding. I think we would need to have a conversation within the team about the pros and cons when it comes to providing this.
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.
+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!
Any updates on this? Am planning to use this for a dotnet commandline tool prototype but blocked on this currently.
@daxian-dbw I think there is a package named StrongNamer on Nuget that can be used to convert any library to strong named, maybe you can try that?