Hangfire failes to load assembly

Question

Context

I have two application in place, one is my main enterprise application and in other I have hangfire (hangfire server, client and dashboard) hosted. My main application also use hangfire for some long task and executes them asynchronously. Both using the same DB for HF storage. And there is only one HF server.

Issue

I am getting the following errors intermittently -

"Can not change the state to 'Processing': target method was not found." OR

"Can not change the state to 'Enqueued': target method was not found."

with following details -

System.IO.FileNotFoundException

Could not load file or assembly 'MyApp.Hangfire, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.

where MyApp.Hangfire is my hangfire application executing jobs. And I am sure that it is there, and even some successful jobs affirms it.

Please find the attached screenshot for more details.

Observation

The issue is not consistent, the job not always fails, sometimes it fails, re queued and get passed and sometimes when it is out of retries it even fails. As shown in screenshot

Hoxsie

What version of Hangfire are you using? – Stoltz

@TomRedfern: I am using the latest version of HF, i.e 1.5.3 – Hoxsie

If you requeue the job, it always fails? – Stoltz

@TomRedfern: Not always, sometimes it passed and even fail at times. I have also rechecked, and there is only just HF server, no other applications are using the same HF DB. Not even IIS reset is there. :( – Hoxsie

@Hoxsie any update on this issue? I am trying out hangfire and i am having the same problem. I raised an issue about it github.com/HangfireIO/Hangfire/issues/558 – Facelifting

@Facelifting - In my case the HF database got corrupted, so I just created a new empty DB for HF with new name and it got working properly. – Hoxsie

Had the same experience as @Yogi, new DB did the trick. In my case the problem was sometimes solved after a recycle of the application pool (which re-creates the background workers). The after a new recycle the problem was back again. – Understate

@FrankBakker - I have not encountered with the same issue again, if the problem is coming again in your case, make sure that there are no other application instance accessing the HF db – Hoxsie

Answer 1

I've stumbled upon the same issue a few days ago and decided it's worth adding it here.
Solution: added a reference to 'MyApp.Hangfire' in the dashboard web app.

Context was very similar or identical to yours:
-Hangfire server was running as a Windows service;
-Hangfire dashboard running on top of a ASP.NET MVC 5 app;
-jobs were actually running but dashboard kept displaying a FileNotFoundException;

Same problem was reported and solved in the same way by @reggieboyYEAH.
Details here: https://github.com/HangfireIO/Hangfire/issues/558

Architectonic

The issue you described is not the same as the OP's issue. But just has to do with the dashboard needing a reference in order to display job details properly. The jobs are actually executed just fine. In the OP's case (and mine), both the dashboard and the job server already have the required references, but jobs outright fail intermittently and are retried. The jobs sometimes succeed and sometimes they fail – Interinsurance

@dannie.f: sorry I couldn't help. Did you find out what it was? – Architectonic

@razercool I went through the hangfire github page and found several issues relating to the problem described. See #908 and #910 for example. I will add an answer with a work around incase it helps other people – Interinsurance

@razercool The OP indicated his problem was due to a corrupt db. The observation of intermittent failures with "File not found" exception described in the github issues actually have roots in a hangfire limitation. I was going to add an answer, but it would not have addressed the OP's specific problem. But in case it is useful to other people, If using multiple servers with one database, the error can be fixed by ensuring all servers reference all job classes even those it can't execute. ie. Server A must reference jobs for server B as well and vice versa. – Interinsurance

@dannie.f: Thanks! All makes sense. – Architectonic