Common Assemblies

question
1

I am trying to set up a distributed scenario with Hangfire.

  1. The client application - an MVC Web App responsible for queuing jobs. It will not be responsible for processing the jobs. (Deployed to Application Server A)

  2. The processing (server) application - a Windows Service that will process the jobs queued by the client. (Installed on Database Server B)

I tried following the advice in the following discussion with respect to creating interfaces in the client and concrete implementations of them in the server application.

http://hangfire.discourse.group/t/dashboard-can-not-find-the-target-method/210/4

The problem is that I consistently get the following error:

Failed Can not change the state to 'Enqueued': target method was not found.
System.IO.FileNotFoundException

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

It appears as though the reason for this is that I am not using a “common assembly” that the two applications share. How would I go about doing this?

2

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!

Please take a look at : https://github.com/gandarez/Hangfire/tree/assembly-resolver
Also I did a PR to Hangfire master : Store 3rd party assembly's file location to be used as AssemblyResolver when resolving Type by gandarez · Pull Request #486 · HangfireIO/Hangfire · GitHub

3

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

4

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!

Do a try and tell me if it works for you.

5

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?

6

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?

7

Is there any thought on if (or when) this code modification might make it into the hangfire package? This solved a huge problem for us that I can see many others having.