Hi @Matthew_Koch I faced the same problem as you’re having. I forked the repo and did a workaround which works in most cases. It simply stores into the hash the assembly’s location and resolve when getting its type. For me it’s working like a charm!
@gandarez Thanks for the reply. I see the changes you made in Github. I’ll have to give this a try in my project. Any idea if something like this is being considered for a merge? I’d imagine it’s a common scenario to split processing apart from client applications.
It’s what I expect unfortunately a good product/project can not stay frozen for a long time without taking care of PRs. I’ve submitted this PR almost 1 month ago and didn’t get any responde or comment!
I’m actually still unsure how this even works if we are using apps on two different servers.
When the “client” app queues a job, it gets added to the Hangfire database. The “processing” app needs to pick this job up and process it, and from what I understand also needs to have the same class/method as requested by the client. Does the name-spacing have to be exactly the same between the two apps? That is, if one is a Web app and one is a Windows service, do they both need the exact same namespace to resolve back to the right assembly?
Just bumping this in case someone has some insight on this topic. The main question seems to be - how can we share binaries or code between two solutions?
Consider the scenario where we want a single Hangfire server to send mass e-mails. Many client applications might want to queue messages, but we only need one server to process them. How do we share the code required for these disparate systems to speak to one another?