Hangfire: Have one dashboard for Multiple project

[osmanrahimi]

I am using Hangire in multi projects with the same Database , but I have Problem when I launch to Dashboard for some Jobs that runned from another Project it cant show Job's name so I get this

Can not find the target method.

It just show name for jobs in Project's that Contains Dashboard

[pieceofsummer]

Dashboard needs access to assemblies containing job methods to display the jobs, the same way as Hangfire Server needs to access them to execute the jobs.

If your projects are related, they could be merged into a single solution. If they're not, it is logically incorrect to give them access to the same database, where one project can mess with the data of another one.

[snakenstein]

If your projects are related, they could be merged into a single solution. If they're not, it is logically incorrect to give them access to the same database, where one project can mess with the data of another one.

Is Hangfire indended to be used only in monolitical applications?

[NitinJain27]

Any update on this. I am using 2 separate hangfire projects --> 1 has 2 jobs and another has 5 jobs and both uses same database. Opening hangfire dashboard UI for both the projects shows same jobs while both the projects has different jobs. In server section of hangfire UI it shows 2 servers with same name : different guid

[danielfoxp2]

I have the same issue here.

We have 2 projects and 2 hangfires, one for each project. Both uses the same database and this setence bellow of @pieceofsummer does not apply to our architecture decisions:

[...], it is logically incorrect to give them access to the same database, where one project can mess with the data of another one.

The problem is that when I run the hangfire dashboard of the project 2, I see jobs from project 1 that shouldn't be presented and vice-versa.

The use of the same database doesn't mean that all the jobs should be visible to all projects using it. In my point of view, hangfire should show only the jobs related to the project where the job was defined and allow otherwise only if the developer configure so.

[burningice2866]

Are you making sure that each project is using its own table schema so tables from each project is effectively separated and not visible from eachother?

[danielfoxp2]

How's that? They share the same database. The database tables are created by hangfire itself, if they target the same database, they use the same tables, don't they?

I looked around after what you said and found this issue: https://github.com/HangfireIO/Hangfire/issues/1163

Maybe this could work for us. But it's not, in my opinion, the ideal solution.

Anyway, we ended up with another approach to the problem and we have only one Hangfire now. Thanks.

[burningice2866]

Schemas are for partitioning a single database into multiple logical compartments - you can have multiple identical table names in the same database as long as they are separates by schemas.

You can see it as databases within a database. Per default all tables are in the dbo-schema and you wouldn't normally think about schemas. Unfortunately not enough people know about schemas and find them selves making all kinds of workarounds instead of making use of the features a database gives.

[danielfoxp2]

Back in 2017 I made a system where customers were separated by its own schema. Know about them, just don't feel right to do it because hangfire. I think hangfire shouldn't have this behavior or, at least, it should be configurable. That's why I'm here enforcing a discussion about it.

The use of schema is a kind of hack in order to make Hangfire to work properly.

Even if you say that this behavior is a feature, well, what is the explanation about the use of it in the customer perspective? I mean, it will show the jobs from another project but an error message will be present in the job name stating that some .dll couldn't be loaded. It serves for what?

[burningice2866]

If you have two different projects using the same database, how is it a hack to use a different schema for each project?

IMO its a hack that you use the same database for two different projects in the first place, but I've been in the game long enough to know that's just sometimes the terms given by dba's.

Why do you think Hangfire1 will show jobs from Hangfire2? When separated by schemas Hangfire1 will never know that there exists any Hangfire2 and will therefor not show any jobs from that project. Tt could just as well have been in two separate databases, that's what schemas are for.

[danielfoxp2]

It's two different projects, not entirely different contexts. They share a lot of things in the database level. Our architecture was developed taking our needs in consideration. In our case, the schema would be used only to make hangfire works properly, that's why for this target it would be a hack.

Why hangfire shows jobs from another project if it serves no purpose??? Is it not a problem?

[berdem]

Feeling the same.
Having a one db for multiple applications is not a hack. It's a fact. It's a real world case.
I hope i would see Hangfire manages to serve in 1 db and 1 set of tables with multiple server instance from completely different applications without a shared dll for the jobs.

[kavhad]

A system I'm working on is designed as dozen or so microservices which are used in one project. We have started to use hangfire with it's dashboard to run and manage our background jobs. I would have preferred that we only needed one hangfire instance and dashboard and each microservice worked on an exclusive hangfire queue so that incompatible workloads where not run by wrong service. I know that this would go against the microservice principle of separate database per microservice, but it would have been more pragmatic in our case.