Why we need Hangfire to be strongly named

question
1

I’ve posted on this before but I want to re-iterate why it is important to us, and I would really like to know when it will become available.

We are required for compliance reasons to strong name all our application assemblies - because Hangfire is not strongly named, we simply cannot use the default NuGet distribution.

In order to use Hangfire, I had to do the following:

  • Use the Nivot package from NuGet to apply a strong name to unsigned assemblies (Dapper, HangFire.Core, HangFire.SqlServer)

  • Our assemblies can then compile against Hangfire, but the code fails at runtime because there are InternalsVisibleTo attributes declared in the Hangfire assemblies which do not reference the public key. Unfortunately, Nivot does not provide a solution for this.

  • To solve this, I used Reflector with the Reflexil plugin, which allows me to remove the InternalsVisibleTo attributes directly from the assemblies, as they don’t appear to be required for the runtime operation of Hangfire.

After all that, it works. Of course, I have to repeat this process every time I get updated Hangfire assemblies.

Obviously it would make life easier for us if all of this wasn’t necessary! Even just changing the structure of the assemblies so that InternalsVisibleTo attributes are not included in the final build would remove one hacky step for us.

Please add strong names where required to Hangfire, most of the dependencies are already strong named so it shouldn’t be difficult?

3 Likes
2

I’m facing the same issue today.
We’re also rerquired to strong name all our application assemblies.

1 Like
3

Im also facing the same issue.

4

Workaround:
I found the following nuget package very useful, that takes care of signing every reference of a project during build. A build target for singing all reference is added automatically since the most recent version. For me, it worked with Hangfire. It also works when called from console.

Nuget

Project

1 Like