Hangfire: Changing namespace causes error loading a job

[mgroves]

I have a hangfire recurring job setup like so:

RecurringJob.AddOrUpdate("nightlyCsvExport", () => myCsvExportService.ExportCsv(), Cron.Daily(2, 0));

That was working fine, until I changed the namespace of myCsvExportService's class, and now I get an error like

TypeLoadException: Could not load type 'MyProject.Core.MyCsvExportService' from assembly 'MyProject.Core, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'.

First, is this a known issue/bug? (I couldn't find an issue). Reproducing is as simple as changing the namespace after the job has run for a while. I'm not sure what the expected behavior would/should be...

If it's not a bug, how should I address this? Since this is just in development for now, I'd be fine with a total reset. But is there another way I should approach this? Should I just avoid changing namespaces? Should I just change the recurringJobId whenever I change namespace? I could also use reflection to get the fully qualified name and use that in the recurringJobId (but is that overkill?).

[burningice2866]

You should delete your nightlyCsvExport job first and then call AddOrUpdate as normal.

I presume Hangfire don't see the namespace change as a reason to update the registration in the database, and it therefor still points to the old namespace.

[burningice2866]

This is the method that in the end decided whether the data in database should be updated when you call AddOrUpdate

https://github.com/HangfireIO/Hangfire/blob/da234b30fb3efe32d3cc98599e94322bb694c251/src/Hangfire.Core/RecurringJobEntity.cs#L121

and is called from here https://github.com/HangfireIO/Hangfire/blob/da234b30fb3efe32d3cc98599e94322bb694c251/src/Hangfire.Core/RecurringJobManager.cs#L111

[mgroves]

You should delete your nightlyCsvExport job first and then call AddOrUpdate as normal.

I did that, in a roundabout way. What's the best way to delete a job?

Do you think this is something that IsChanged should check for?

[odinserj]

@mgroves thanks for reporting this. Although I can't say this is 100% a bug, but I don't see any reasons to prevent updating such a recurring job. AddOrUpdate doesn't use previous job method information in any way and no filters are able to intercept this change. So instead of throwing an exception, it's better just to update it.

[mgroves]

@odinserj terrific, thank you! I haven't tried it out yet, but it makes sense to me. For future reference, what is the best way to delete a job?

[odinserj]

It will be available only in upcoming 1.7.2 release. Regarding deletion, try RecurringJob.RemoveIfExists method.

[BramMusters]

I still have issues using version 1.7.2: when changing the namespace, I get the same exception as described above. This issue also arises when the method signature changes.

Removing the Recurring Job first seems to be the only solution.