Could strong names PLEASE be added to Hangfire assemblies - we have to sign all our application assemblies with strong names, which means we can’t use Hangfire at all.
We really want to try this framework but we can’t even get started because of this.
Thanks!
Sam
I also want them signed as it makes life easier, but you can certainly self-sign them, it’s just a nuisance. This will do it, for instance:
ildasm /all /out=tempfile.il hangfire.dll
ilasm /dll /key="path_to_your_own.snk" tempfile.il
Also, maybe easier depending on your comfort levels, you can just get the source code and add the signature file the same way you do to your own DLLs.
Yes, but the whole point of NuGet is gone.
Honestly, Hangfire is first Nuget package, that I have found unsigned. I don’t think it is that hard to create signed NuGet packages.
I agree. Please please add strong naming to the assemblies from nuget. I notice that Dapper, which I think was the only remaining unsigned dependencies of Hangfire.Core introduced strong naming about 2 months ago. This hopefully means it’s now much easier to start signing the Hangfire assemblies.
Thanks in advance!
Guys, can you tell me why do you need strong naming? Is it your company’s policy or anything else? The fact that the upcoming AspNet vNext / CoreCLR from Microsoft doesn’t support nor use strong naming means that strong naming is effectively dead for server side .NET development. However, I understand that some companies use different policies.
Strong naming is a lot of work, including further topic investigation (and reading this looong discussion) so I want to know the real reason before making and decisions.
I’ve already posted why we need it in this thread.
I don’t care what vNext is doing - we need this support now. If things change in the future, then so be it.
Plus, I’ve already strong named Hangfire myself, it took me 5 minutes, so I don’t know what could possibly be the issue for you to do it from your side.
@phaedrus30, thank you for that informative post. I believe that you do need the strong naming, otherwise you’d never do the described actions. However, I should understand the exact reason to make the decision, i.e. what do you mean by the following words:
We are required for compliance reasons to strong name all our application assemblies
Strong naming a given set of assembly files for one’s company needs really takes 5 minutes. But you are asking me to make a project level decision, so please don’t tell me about 5, 48 or 132 minutes, as the consequences of such decisions stay for months and years. I’m sure people in that long discussion aren’t talking about non-meaningful stuff.
Thanks for the reply Sergey. Essentially it’s standard practice on my projects because we do a lot of SharePoint development. SharePoint forces us to use the GAC, which requires us to use strongly named assembly references. Sadly, Hangfire is the first instance where I’ve installed a Nuget package to find that the assembly is not signed.
I totally understand your position and I’m not sure what I’d do in your shoes! SharePoint is unlikely to be a major consideration for you. There are workarounds available for us, but they are a little disappointing and hacky. I’ve forked your repo and made a commit here. It was a little fun to unravel and I’m still also dependent on Nivot to sign the other remaining unsigned references pulled down from nuget.
Apart from this, Hangfire has been a joy / lifesaver to work with, so thanks!
Hi Sergey,
We are an ISV with Microsoft Gold partner status - in order to maintain this status, our application must be tested by Microsoft on a consistent basis, and one of the rules of testing is that any .NET assemblies used or produced by the application must have both a strong name and digital signature applied.
If we don’t comply, we don’t keep Gold partner status, which is critical to our business.
I understand that there is debate on whether strong names should be applied or not, but Hangfire really is in the minority here. Almost every 3rd party library I have ever used has used strong naming, purely to be as accessible as possible.
If strong names become redundant in the future then everyone will have to adapt, but right now our hand is forced.
Hangfire is extremely useful for us and we really want to continue using it as it solves a lot of otherwise difficult problems, but we are also dependent on a couple of big hacks to use it in our software.
Can you please describe why you are opposed to strong naming, and what makes it a major decision? I’m really not meaning to be rude and I apologise if I am coming across that way, I just want to understand why this is not a simple update for future releases.
Our company is in the same way. We aren’t Gold yet, but Silver on the go to Gold.
As others comment here, was strange for us too see an NuGet assembly not signed. sick.
As @phaedrus30 asked:
Hello @sergey,
Thank you for this incredible library!
It looks like assembly signing will be supported in ASP.NET 5:
http://blog.3d-logic.com/2015/11/15/creating-and-using-strong-named-assemblies-in-asp-net-5/
Moreover signing is part of the best practices recommanded by Microsoft as part of rule CA2210.
Justification of the rule is given by MSDN:
https://msdn.microsoft.com/en-us/library/ms182127.aspx
So why wouldn’t you sign the assembly now?
Yanal
I’ve always hated this type of attitude. “We need it so adjust your entire project path to suit us when we could take 5 min of our own life to do it ourselves”
I think a little bit differently… They could fix this problem to save 5 min of everybody else… but that’s just my 2 cents.
Any progress here? Hangfire is one of a handful of NuGet packages that are not signed, and are throwing all kinds of chaff into our dependency chain.
We distribute a licensed web application, and require strong name signing to ensure the integrity of our licensing code is not compromised.
We have actually had to maintain a fork of the Hangfire codebase which we sign ourselves, and it would be much easier for us to track updates if Hangfire was signed by default.
I’ve got yet another scenario where a signed version would be useful.
I maintain an open source Storage of Hangfire based on Redis and anyone who also uses Redis Asp.Net Cache provider must use StackExchange.Redis.StrongName can’t use that storage due to Assembly naming loading conflict.
Thanks to @ryanelian who created a Strong-named version of this storage, we could solve the problem for anyone who uses Redis Asp.Net Cache provider but we’d need a signed version of Hangfire.Core.
Any chance to accept a PR ?
Good Day All
Can anyone please help me with this error I am trying to run the Yoco job locally but I am getting the below error, I have googled and tried a few things but it does not work it still gives me the same error.
I’m in the general consensus that the HangFire assemblies should be signed
I agree it’s something that we can all do ourselves. However rather than push back asking why we all want it (plenty of valid reasons mentioned above), maybe you should tell us why you are resisting doing it? The fact that MS will or may not support it in the future will not wash. There is plenty of legacy code out there in production that needs this resolving.
I’m in the same boat, we have a policy that must be enforced which means we have to manually sign them each time we upgrade and of course, this negates the ease of using nuget for deployment. We are also a Pro subscriber and use the product in production
Any update on this, just installed Hangfire in a project which gets signed and wont build now because hangfire isnt signed .
