Use of GlobalConfiguration and static fields makes testing more difficult

[matt-psaltis]

We have a number of cross cutting tests that involve our DI container (Autofac) and Hangfire. When testing these sub-systems. I am trying to stand up our container with new instances of Hangfire for each test.

Currently lines like this one: Static interlocked check to avoid additional execution

Makes tearing down Hangfire really tricky and I'm having to replace Service Descriptors in the IServiceCollection to make sure Hangfire is bound to the correct Activator and Logging instances for each test.

[Sumo-MBryant]

Ideally there should be no statics at all, and all constructors should take in the required dependencies.

I'm also having issues with ILog being initialised as a static for many classes.

[TripleEmcoder]

Really don't want to sound too grumpy here, as I am very grateful for all the work done on Hangfire. It's a great tool that solves a lot of complicated problems, and a very useful building block. That said... The move to .NET Core is half-backed, unfortunately. On the surface you get all the Add and Use extension methods on IServiceCollection etc., but they all lead, one way or another to global state in GlobalConfiguration.Configuration, JobStorage.Current, JobActivator.Current. This leads to various issues when configuring multiple applications in a single process space, like when doing integration testing with WebApplicationFactory. Worst thing is that it's so unexpected. If the docs showed GlobalConfiguration.Current.UseWhatever instead of services.AddHangfire, there wouldn't be so much confusion. Are there any plans to refactor configuration to behave more in line with ASP.NET Core conventions?