Strong name signing

[Kemyke]

We are using this great library in an environment where every package is signed. Currently we are signing this library during our build process. However it is currently fine but it would be great if you can sign the library. What do you think about this?

[canton7]

Sure, I'll look into it. I'll have to see if there are any implications or compatibility-breaking changes for other users: I know some libraries publish separate NuGet packages for signed / non-signed versions, for instance.

[roryprimrose]

It shouldn't be a breaking change unless you roll a signed package using a previous version and someone consumes one of its types using the fully qualified type name.

[canton7]

Looks like the issue quite a bit more complex than I'd anticipated:

• 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.

[chadly]

Please don't do this. Strong naming is the bane of my existence. I'd rather you just recommend Strong Namer for the people that really want it.

[Nick-Lucas]

+1 to using StrongNamer, I use this for WPF/ClickOnce deployments and it does the job great

[apopovsky]

Any updates on this?
We have the same problem. We want to use it in a project but a strong name is required.

[canton7]

The current status is that I've had 2 requests for strong naming (including yours), 1 request not to strong name, and a workaround proposed.

If you have experience with strong naming NuGet assemblies (which addresses the 4 points in my post above), and can contribute towards the effort, then I don't see the issue with releasing a second strong-named assembly...

[Nick-Lucas]

The simplest solution really is to use StrongNamer, it resolves the issue automatically with a build hook.

I know of very few NuGet libraries which are signed, and doing so has the potential to introduce its own issues.

[StefH]

StrongNaming is very easy, just follow these steps:

1] create a key sn -k RestEase.snk

2] edit csproj file, add these 2 lines in the element

    <AssemblyOriginatorKeyFile>RestEase.snk</AssemblyOriginatorKeyFile>
    <SignAssembly>true</SignAssembly>

3] In case you use InternalsVisibleTo, execute these:
sn -p RestEase.Net.snk public.key
sn -tp public.key

And copy the public key (only the numbers) into the InternalsVisibleTo like:

[assembly: InternalsVisibleTo("RestEase.Tests, PublicKey=002400.....97")]

If you want to see it working, take a look at https://github.com/StefH/System.Linq.Dynamic.Core/

[StefH]

@Nick-Lucas It seems that StrongNamer is not supported in dotnet (.net core projects)?

[lucaspimentel]

FWIW, the recommendation in non-Windows platforms was to "public sign" the assembly by adding <PublicSign> property to the project:

<AssemblyOriginatorKeyFile>RestEase.snk</AssemblyOriginatorKeyFile>
<SignAssembly>true</SignAssembly>
<PublicSign Condition=" '$(OS)' != 'Windows_NT' ">true</PublicSign>

From the C# compiler docs:

Sometimes called "fake sign" or "OSS sign", public signing includes the public key in an output assembly and sets the "signed" flag, but doesn't actually sign the assembly with a private key. This is useful for open source projects where people want to build assemblies which are compatible with the released "fully signed" assemblies, but don't have access to the private key used to sign the assemblies. Since almost no consumers actually need to check if the assembly is fully signed, these publicly built assemblies are useable in almost every scenario where the fully signed one would be used.

More details in the CoreFX repo. Also, this thread. Following that thread, however, TIL that signing is now supported cross-platform.

[justkao]

Please reconsider strong-naming this assembly. This issue has been discussed over and over again but recently Microsoft actually made a official statement recommending that all OSS nuget packages should be strong named.

https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/strong-naming

As an alternative RestEase.Signed assembly can be produced as a side nuget package.

[canton7]

In fairness, that article does say

✔️ CONSIDER strong naming your library's assemblies.

And it also says:

❌ DO NOT publish strong-named and non-strong-named versions of your library. For example, Contoso.Api and Contoso.Api.StrongNamed.

Which I interpret as a weak recommendation to strong name, and a strong recommendation not to have both a strong-named and a non-strong-named version of the library.

The 4 points in my original question are still awaiting answers. If you have any input on those please provide it!

[justkao]

Sorry I can only provide the input about the 2th and 4hth question.

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 is actually not true anymore, it's easy to sign the assemblies now using the new project system by using the <SignAssembly> tag.

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

The official recommendation is to commit the key into the source system.