Support Quartz.NET like Sentry.Hangfire

[michaelmairegger]

Problem Statement

I use Quartz.NET for background job scheduling. Simply like Hangfire it would be cool to have a possibilty to use it with Quartz.NET

I will provide a PR for this issue soon

Solution Brainstorm

No response

[linear[bot]]

NET-483

[michaelmairegger]

I have pushed my changes. If desired I can create a PR for this changes

[Flash0ver]

Thanks for the request, @michaelmairegger.

To be fair, taking a look at usage, Quartz.NET has roughly half of Hangfire: NuGet Trends

But if maintenance of Sentry.Quartz would be comparably low to the maintenance of Sentry.Hangfire, it seems like a fine addition to the ecosystem.

Quartz is currently targeting net462, net472, net8.0, net9.0, and netstandard2.0. Hangfire.Core is currently targeting net451, net46, netstandard1.3, and netstandard2.0.

[Flash0ver]

And also thanks for your intended contribution, @michaelmairegger. Much appreciated! Now me not being too experienced with Quartz.NET, would you mind linking your branch / fork, so that we can get an idea of the complexity, before going into the PR phase?

[michaelmairegger]

@Flash0ver the complexity is of scale of Hangfire. This commit covers pretty much everything: https://github.com/michaelmairegger/sentry-dotnet/commit/ebced5a149feb0a18b796ab85633e745f2be9f47 I am using this codebase in all of my products. Since the sentry ecosystem helped me a lot with different problems I thought to give some value back

[Flash0ver]

Amazing ... thank you very much! Before entering the PR-phase and getting down to the nitty-gritty, I got an architectural question, again, due to my lack of XP with Quartz.NET:

When it comes to dependencies, we try to have our cake and eat it too: With a minimum amount of dependencies to help keep the transitive tree of consuming projects sane, with a reasonable version of dependencies for broadest reach.

Would it be reasonable to apply / consider these changes in dependencies?

• remove Microsoft.Extensions.Logging.Abstractions
  • instead of using M.E.L.ILogger`1, can we use Sentry.Extensibility.IDiagnosticLogger instead
  • considering these are "diagnostic" or "debug" logs out of the SDK
  • also considering that Quartz already depends on Microsoft.Extensions.Logging.Abstractions
• lower from Quartz.Extensions.DependencyInjection to Quartz
  • does the "base" package suffice for a high-fidelity Quartz.NET-integration
  • our would the provided value then be insufficient for common scenarios

[michaelmairegger]

• replaced M.E.L.ILogger^1 with Sentry.Extensibility.IDiagnosticLogger
• Quartz.Extensions.DependencyInjection is required since IServiceCollectionQuartzConfigurator is present there. With upcoming Quartz v4 all packages will be merged, then Quatz is the only dependency

[Flash0ver]

Thanks. Do you know around what time (approximately) Quartz 4 is scheduled to be released?

Considering the breaking changes between v3 and v4 (including the dependency change you mentioned and a change of usage from Task to ValueTask in the public API), and that we usually only do (significant / widely impacting) breaking changes around this time of the year (.NET vNext release), as well as us trying to avoid to having mulitple integration packages (Sentry.Quartz3 and Sentry.Quartz4), @jamescrosswell and I were thinking about adding the Quartz-integration together with Quartz v4.

What do you think?

[michaelmairegger]

I do not know about the ETA of Quatrz 4. But I agree that wating for Quartz v4 would be reasonable

[Flash0ver]

• quartznet/quartznet#988