Published NuGets are not strongly-named assemblies

[TheAtomicOption]

The current NuGet package for v1.0.5^* is not built as a strongly-named assembly. This is prevents using it in an assembly that is required to be strongly-named/signed. This impacts me since my current project is used in the GAC.

After reading around, it looks like the optimal solution may be for whoever is uploading the binary of this package to strongly sign it locally before uploading it: http://disq.us/p/oog81l

Microsoft themselves currently recommend:

If you are an open-source developer and you want the identity benefits of a strong-named assembly, consider checking in the private key associated with an assembly into your source control system.

Either of these should work since strongly-naming assemblies is about identity, not security. There are some workaround hacks I could do such as assembling from source or disassembling/reassembling to add my own signature locally. But it'd be much more convenient for other users to just fix the Nugets.

^{* I'm targeting this version because my project is currently stuck in .NET 4.5.1 while further versions of SmartEnum are requiring .NET 4.6.1+}

[ardalis]

I'm open to this. The upload to Nuget process is automated into our build/release pipeline in Azure DevOps. The delay here is simply in me having the time to figure out how to incorporate strong naming into that process.

[redwolf2]

Please sign your assemblies, otherwise they can't be referenced from strong signed assemblies.

Users will get an error like:

"Referenced assembly 'xxxxxxxx' does not have a strong name"

if they add your assemblies to a strong signed project.

See also: https://docs.microsoft.com/en-us/dotnet/standard/assembly/strong-named

You can do this in your project settings under:

[VMelnalksnis]

I'm open to this. The upload to Nuget process is automated into our build/release pipeline in Azure DevOps. The delay here is simply in me having the time to figure out how to incorporate strong naming into that process.

Any update on this?

From my quick search, I see that InternalsVisibleTo is not used, so unless I'm missing something, all that needs to be done is to add

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

to each project and generate the key, which should be done automatically by checking Sign the assembly under project properties in Visual Studio/Rider. I could see some difficulty in correctly setting up assembly file versioning according to MS recommendations depending on your ci setup, in order to reduce binding redirect changes.

[VMelnalksnis]

I created a fork with assembly signing, here is the commit https://github.com/VMelnalksnis/SmartEnum/commit/b53e8bd874358ea4e1201097f3dec8d94e12ab23. There are some new warnings for SmartEnum.Dapper:

1. The referenced version of Ardalis.SmartEnum is not signed; I guess bumping that is part of your release process
2. Dapper is not signed; that issue has been planned to be resolved in the next release for 3 years. There is a Dapper.StrongName version, however Dapper.Contrib is also not signed, so I guess it's better to just stick with Dapper

[steve-nickerson]

would also love to hear if there is an update on this? I am working with a very old .net462 monolithic repo and it requires a signed assembly. currently trying to work with v1.0.8 as it is last version with framework target.

was hoping that if in my separate netstandard2.0 project that references this pkg if i signed THAT it would be ok, but does not appear to work that way. @ardalis

[ardalis]

@VMelnalksnis if I generate a key (how?) then can I check that in or do I need to keep it secured somewhere (perhaps in GitHub secrets?). I've never needed a strong named assembly so even though this is probably easy stuff it's outside my knowledge base and the little bits of friction have been enough to keep this from happening.

[VMelnalksnis]

I've personally only generated the key from Visual Studio/Rider, the steps were described above. There's also a separate, probably windows only, app for generating the key, see https://learn.microsoft.com/en-us/dotnet/standard/assembly/create-public-private-key-pair.

For my packages which support .NET Standard/.NET Framework I created a key file per package, and checked it in following the guidelines from Microsoft here:

If you are an open-source developer and you want the identity benefits of a strong-named assembly for better compatibility with .NET Framework, consider checking in the private key associated with an assembly to your source control system.

[TheAtomicOption]

Confirming that yes, it's normal to check the key into the repo for projects like this. Strong naming was created for identity not for security.