search

HangfireIO / Hangfire

An easy way to perform background job processing in .NET and .NET Core applications. No Windows Service or separate process required
https://www.hangfire.io
Other
9.45k stars 1.71k forks source link

Hangfire.Core dependency on Owin #621

Open tompazourek opened 8 years ago

tompazourek commented 8 years ago

I have a class library project that contains some job classes. I want to use some of the Hangfire attributes to configure how the jobs should behave (e.g. AutomaticRetry).

That means that I have to install Hangfire.Core together with Owin. It makes no sense for me to have dependency on Owin in a class library, I just want to use Hangfire attributes.

I think there are some opportunities to improve the Hangfire architecture. If I just want to use Hangfire attribute in my class library, why should I need Owin?

I don't feel competent enough to help with this through a pull request, and it would probably require big structural changes that I guess you'd prefer to do yourself anyway.

I really appreciate the hard work you put into this project.

Any thoughs on this?

TheBeardedLlama commented 8 years ago

it almost sounds like they should be split out into their own assembly/package with minimal dependencies that .core then references...

burningice2866 commented 8 years ago

I addresses this issue back in March https://github.com/HangfireIO/Hangfire/issues/527 but there was no feedback so i didn't give much more thought.

odinserj commented 8 years ago

There is OWIN package, and there is Microsoft.Owin package. The former is abstraction, and the latter is implementation. Hangfire.Core only depends on abstraction, it is very slim, contains just one interface, and actually this is not a problem to have that dependency.

Without that dependency there will be much more packages for basic Hangfire features, that will result in even more extension packages. For example, if there are Hangfire.Core and Hangfire.Dashboard, there would be Hangfire.Pro and Hangfire.Pro.Dashboard also to live in a world of correct dependencies.

Nevertheless, with new ASP.NET Core this is an inevitable step, because it adds some confusion for those who use it with full .NET framework. But this is a breaking change, and will be made only in 2.0.