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.
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.
@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!
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.
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