Jobs start immediately even if ToRunNow() is not called

[thomasrea0113]

    public class TestRegistry : Registry
    {
        public TestRegistry()
        {
            Schedule(() =>
            {
                while (true)
                {
                    var log = NLog.LogManager.GetLogger("Logger1");
                    log.Info("sleeping 1...");
                    Thread.Sleep(100);
                }
            })
            .WithName("Infinite Task")
            .NonReentrant()
            .ToRunNow();
            Schedule(() =>
            {
                while (true)
                {
                    var log = NLog.LogManager.GetLogger("Logger2");
                    log.Info("sleeping 2...");
                    Thread.Sleep(100);
                }
            })
            .WithName("Infinite Task (Not Running)")
            .NonReentrant();
        }
    }

The above registry will start both jobs even when ToRunNow() is not called on the second schedule. Ideally, the Registry class should make Schedules public so that we can retrieve scheduels at a later time and run them manually. Alternatively, One-off jobs should also be added to AllSchedules (or another AllJobs property should be made available) so that each job can be registered and scheduled at a later day. That should only require adding the job to the collection above this line.

My use-case right now it to create a task schedule - so I need to define the jobs now, and let the user schedule them at a later day. I don't want them to run at startup. For this purpose, registry is essentially useless. I'll be better off subscribing to the job events and manually calling add/remove job.

[tallesl]

You're totally right, I'm also aware of that. I'm flagging this issue as a bug and leaving it open.

Being honest here: since this doesn't affect the other schedules, and there's an on-going library redesign, I'll probably not fix it.

[thomasrea0113]

You're totally right, I'm also aware of that. I'm flagging this issue as a bug and leaving it open.

Being honest here: since this doesn't affect the other schedules, and there's an on-going library redesign, I'll probably not fix it.

Thanks for the update! As long as the redesign keeps my points in mind, I'll be happy. This project is my favorite open source scheduler by far, and these improvements would make things so much easier

[tallesl]

That's so kind of you, thanks.

I'm doing some quality of life updates on version 5 (mainly newer .net standard and async job support) and some housekeeping on existing issues, then I'm back to work on version 6 (currently in alpha).

As for being your favorite open-source scheduler, please stay around. It's taking ages, but we're so close to finishing up version 6 (it's just missing reentrancy IIRC). After that, it should be much more pleasant taking new features suggestions and accepting merge requests.

[thomasrea0113]

Just wondering what the status was on this? I'd still love to see this, and it seems at least one other user is looking for something similar.

ce6b4d6#commitcomment-44086754