Hangfire Discussion

Why we need Hangfire to be strongly named


#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?


Please add strong names to Hangfire assemblies
#2

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


#3

Im also facing the same issue.