nulltoken

If that's ok with you 'm going to try and give it a go. I'll ping back with an early spike to gather feedback.

>If possible, the solution should be backward compatible (semantic versioning). Otherwise, we have to target this feature for v4. I've thought about that. Hence the "gather feedback" step :wink:

@linkdotnet I followed a quick (and somewhat dirty) track that led me into an dead-end, locked in the DI lifecycle. If can think at least of two options: - No...

>In both cases: How would one define dependencies between jobs? non breaking change option: in the same way it's currently done. breaking change version: `Services.UseNCronJob(s => s.AddJob(c => ...).ExecuteWhen(success: s...

I'm interested in playing further with this idea on my spare time. I'll try to find some time to work on the Expression angled approach.

Another use case where the .Add()/.Use() pattern may be useful has been identified in #106. `JobExecutor` relies on `ActivatorUtilities.CreateInstance` which goes in the way of making #54 happen. Below the...

> * `options` wouldn't be an `Action` anymore, but an `Expression` FWIW I've quickly tested this approach and forgot to report here my findings. I've eventually hit a quick brick...

@linkdotnet Do we want to pave the way for this in v4? As identified in #106, we could ``` Maybe add a .UseNCronJob() extension method that would harvest the JobRegistry...

@gravypower :wave: Sorry for the delay in getting back to you. Could you please share a bit of context with regards to your question? Are you facing an issue or...

@gravypower Hmmm. I'm a little bit puzzled. The code below defines an xfn transformer that will set the `sub` and `amr` and copy along the `scope` properties in the token...