[GH-ISSUE #60] Cannot strong-name Hangfire.Core & Hangfire.SqlServer #53

New issue

Closed

opened 2026-02-25 21:30:34 +03:00 by kerem · 3 comments

kerem commented

2026-02-25 21:30:34 +03:00

Owner

Originally created by @achimismaili on GitHub (Apr 7, 2020).
Original GitHub issue: https://github.com/brutaldev/StrongNameSigner/issues/60

I am trying to sign Hangfire.Core, but the tool says, that it is already strong named.
Nevertheless, there is still no PublicKeyToken available. See console output:

PS C:\xxx> .\packages\Brutal.Dev.StrongNameSigner.2.7.1\build\StrongNameSigner.Console.exe -a C:\xxx\packages\Hangfire.Core.1.7.10\lib\net45\Hangfire.Core.dll -k C:\xxx\web\hangfire.snk  -l verbose
-----------------------------------------------------------
---- Brutal Developer .NET Assembly Strong-Name Signer ----
-----------------------------------------------------------
Console application to sign .NET assemblies with a strong-name key and fix assembly references.

Strong-name signing 'C:\xxx\packages\Hangfire.Core.1.7.10\lib\net45\Hangfire.Core.dll'...
Already strong-name signed...

.NET Assembly Strong-Name Signer Summary
0 file(s) were strong-name signed.
0 references(s) were fixed.
PS C:\xxx> ([system.reflection.assembly]::loadfile("C:\xxx\packages\Hangfire.Core.1.7.10\lib\net45\Hangfire.Core.dll")).FullName
Hangfire.Core, Version=1.7.10.0, Culture=neutral, PublicKeyToken=null

But after this signing, the public key is still null --> PublicKeyToken=null
From my understanding, "strong naming" means, that there must be a key available.

I was also not able to sign the dll in the nuget package 'Hangfire.SqlServer' for net45 (packages\Hangfire.SqlServer.1.6.21\lib\net45\Hangfire.SqlServer.dll)

Originally created by @achimismaili on GitHub (Apr 7, 2020). Original GitHub issue: https://github.com/brutaldev/StrongNameSigner/issues/60 I am trying to sign Hangfire.Core, but the tool says, that it is already strong named. Nevertheless, there is still no PublicKeyToken available. See console output: ``` PS C:\xxx> .\packages\Brutal.Dev.StrongNameSigner.2.7.1\build\StrongNameSigner.Console.exe -a C:\xxx\packages\Hangfire.Core.1.7.10\lib\net45\Hangfire.Core.dll -k C:\xxx\web\hangfire.snk -l verbose ----------------------------------------------------------- ---- Brutal Developer .NET Assembly Strong-Name Signer ---- ----------------------------------------------------------- Console application to sign .NET assemblies with a strong-name key and fix assembly references. Strong-name signing 'C:\xxx\packages\Hangfire.Core.1.7.10\lib\net45\Hangfire.Core.dll'... Already strong-name signed... .NET Assembly Strong-Name Signer Summary 0 file(s) were strong-name signed. 0 references(s) were fixed. PS C:\xxx> ([system.reflection.assembly]::loadfile("C:\xxx\packages\Hangfire.Core.1.7.10\lib\net45\Hangfire.Core.dll")).FullName Hangfire.Core, Version=1.7.10.0, Culture=neutral, PublicKeyToken=null ``` But after this signing, the public key is still null --> PublicKeyToken=**null** From my understanding, "strong naming" means, that there must be a key available. I was also not able to sign the dll in the nuget package 'Hangfire.SqlServer' for net45 (packages\Hangfire.SqlServer.1.6.21\lib\net45\Hangfire.SqlServer.dll)

kerem closed this issue

2026-02-25 21:30:34 +03:00

kerem commented

2026-02-25 21:30:34 +03:00

Author

Owner

@achimismaili commented on GitHub (Apr 7, 2020):

Sorry, maybe I do not understand the strong-name-signer solution enough.
I guess it does much more than what I expected ...

When I am running builds, Visual studio had automatically built the dlls in the bin folder with strong names, so there is no need to manually implement any pre build commands in visual studio manually?!

So, the nuget package also automatically adds this functionality, that all unsigned assemblys are signed, just when adding the nuget package?

Hm, then I am still not sure, why it says, that the dll in the packages folder is already signed...?

Maybe just some explanation would be useful here, then the issue can be closed ...

@achimismaili commented on GitHub (Apr 7, 2020): Sorry, maybe I do not understand the strong-name-signer solution enough. I guess it does much more than what I expected ... When I am running builds, Visual studio had automatically built the dlls in the bin folder with strong names, so there is no need to manually implement any pre build commands in visual studio manually?! So, the nuget package also automatically adds this functionality, that all unsigned assemblys are signed, just when adding the nuget package? **_Hm, then I am still not sure, why it says, that the dll in the packages folder is already signed...?_** Maybe just some explanation would be useful here, then the issue can be closed ...

kerem commented

2026-02-25 21:30:34 +03:00

Author

Owner

@brutaldev commented on GitHub (Apr 7, 2020):

If an assembly is already signed then any referenced assemblies it has will not be attempted (it's cached as well). You need remove any signed assemblies (just do a VS clean) which will pick up the additional packages that are referenced such as Hangfire.SqlServer. With the latest version you do not need to do anything, just add the package and it will use the reference list to do the signing. If you change the reference list you will need to clean in order to sign again since a normal build would be incremental and existing signed files would still be in the output directory.

@brutaldev commented on GitHub (Apr 7, 2020): If an assembly is already signed then any referenced assemblies it has will not be attempted (it's cached as well). You need remove any signed assemblies (just do a VS clean) which will pick up the additional packages that are referenced such as `Hangfire.SqlServer`. With the latest version you do not need to do anything, just add the package and it will use the reference list to do the signing. If you change the reference list you will need to clean in order to sign again since a normal build would be incremental and existing signed files would still be in the output directory.

kerem commented

2026-02-25 21:30:34 +03:00

Author

Owner

@achimismaili commented on GitHub (Apr 8, 2020):

Thank you!
Awesome solution! 💃

@achimismaili commented on GitHub (Apr 8, 2020): Thank you! Awesome solution! 💃