MailerService does inherit a base ServiceBase class but the SendFromQueue is defined inside the MailerService class and nowhere else.
O_o this is very interesting… This exception occurs because the type.GetMethod(Method, parameterTypes); returns null value. We can achieve this result when:
- The
typevariable points to different type. Do you have anotherMailerServicetype loaded in your application domain? -
MethodandparameterTypesvalues are wrong, however we can see that they are correct. - Target method visibility is not
public, but we can see it ispublicfrom the code snippet above. - Target method is declared in one of base classes, but you denied it (by the way, this is a wrong behavior).
Do you know other ways to receive the null result after calling the GetMethod method?
this is plain old Reflection that HangFire uses? don’t know what could be wrong here…Is there a way for me to debug into HangFire on this?
Sergey,
this still remains an unresolved issue. Is it possible that somehow the activator does not create a service instance when trying to run the scheduled job? And subsequently doesn’t find the requested method?
My add to queue code works (the MailerService is registered within AutoFac and AutoFac does resolve it at runtime when inside my code):
// add to mail queue (this works)
var queued = await MailerService.AddToQueue(mailMsgDto);
// add to HangFire schedule
BackgroundJob.Schedule<MailerService>(ms => ms.SendFromQueue(queued.Id), TimeSpan.FromMinutes(2));
How does Aufofac activator actually create service instances for background jobs?
btw I added a default constructor to MailerService where I just new() up some dependencies but same exception still occurs
I added Hangfire.Core project to my solution to be able to debug it and the InvocationData.Deserialize() always managed to find the method when in Debug session. Job still failed couple of times then after few more retries it just succeeded one time. However, emails still weren’t sent.
whoa, after debugging this I finally got it resolved. The problem actually was in the SendFromQueue() method which was failing to deserialize our MailMessageDto which we serialized in the AddToQueue() step. The issue was with the System.Net.MailAddress class. This didn’t show up until I debugged deep down into my code.
thank you
Seems that anytime something goes wrong within our jobs the above exception occurs. I just ran into some issues with async which resulted in Thread being aborted exception within my jobs (yes, I know async is not yet supported, just read about that) and that same exception was being thrown within Hangfire.
Is there a way that exception details would somehow be propagated into the Dashboard?
I’m experiencing this same issue. The really weird thing is if I requeue the Background Job a couple of times it will eventually succeed.
Please check if you have multiple Hangfire servers registered (running) with different codebases. In my case, it was our production server and my own development server. I was testing on my own development machine with newer code but the scheduled Jobs somehow ended to be run by the production server (which had old code, lacking some crucial methods etc.) thus resulting in this exception.
1 Like
Spot on! We are two developers on code bases that don’t currently match. Thank you!
We’ve found that LocalDB seems to work perfectly well, e.g. with:
<add name="connstringname" providerName="System.Data.SqlClient" connectionString="Data Source=(LocalDB)\v11.0;AttachDbFilename=|DataDirectory|\local.mdf;Integrated Security=True" />
No stepping on each others toes 
Sure, it does, it’s SQL Server but then you have to keep those LocalDBs in sync with each other…
Not if you are busy developing and are just working locally. In a coffee shop 
Ohh, coffee shops… 90% of Hangfire were made in coffee shops 
I had the same problem and solved this disabling a other server because Deserialize was work on server that dont had new method signature
1 Like
I am new to this.
how to achieve your solution?
that’s exactly what happend to me! thanks you saved me some time… the production server tried to run it, but it didn’t have the function yet. it appears hangfire doesn’t set an owner id of who created what task, it relies on the assumption that different environments will use different databases.