Как правильно организовать цикл с большой задержкой, есть ли разница?
1)

while (true) {
    await Task.Delay(TimeSpan.FromDays(1));
///////do something;
}

2)

Timer.Tick += ()=> ///////do something;

3)

while (true) {
    if(DateTime.Now - lastExecuted < TimeSpan.FromDays(1)) {
        await Task.Delay(TimeSpan.FromSeconds(1));
        continue;
    }
////do something
}

Здравствуйте, varenikAA, Вы писали:

AA>Как правильно организовать цикл с большой задержкой, есть ли разница?

если нужно раз в день неделю — имхо лучше шедуллер в ОС и запуск отдельной автономной задачи.

за сутки компьютер могут несколько раз перегрузить , в таком коде отсчет начнется заново и если будут перегружать чаще чем сутки — то момент запуска кода никогда не наступит.
Придется по сути писать свой шедуллер. Но лучше использовать готовые системные.

Здравствуйте, okon, Вы писали:

O>Придется по сути писать свой шедуллер. Но лучше использовать готовые системные.
Тут кол-во срабатываний не особо критично, ПО может работать очень долго без перезапуска.
Интересно, какой вариант надежней, менее требователен к ресурсам.

Здравствуйте, varenikAA, Вы писали:

AA>Здравствуйте, okon, Вы писали:

O>>Придется по сути писать свой шедуллер. Но лучше использовать готовые системные.
AA>Тут кол-во срабатываний не особо критично, ПО может работать очень долго без перезапуска.
AA>Интересно, какой вариант надежней, менее требователен к ресурсам.

А что такое надежность в твоей задаче ?

Здравствуйте, varenikAA, Вы писали:

AA>Как правильно организовать цикл с большой задержкой, есть ли разница?

Емнип, Task.Delay внутри использует тот же Timer. Т.е., по сути, способа привели только 2.

Timer не держит поток — т.е. меньше потоков — меньше ресурсов. Это если у вас множество задач — тогда будет иметь значение.

Здравствуйте, varenikAA, Вы писали:

Технически в третьем явно больше операций чем в первом, так что он будет как бы хуже. Но в реальности эту разницу будет не заметно.

Во втором как бы еще меньше, но он отличается от первого и третьего по логике — в нем могут быть параллельные срабатывания если "do something" будет выполняться дольше периода задержки.

Здравствуйте, varenikAA, Вы писали:

Если asp.net, то можно использовать https://www.hangfire.io/ или
же Реализация фоновых задач в микрослужбах с помощью IHostedService и класса BackgroundService.

Цикл с задержкой в дни выглядит как-то ненадежно.

Здравствуйте, BlackEric, Вы писали:

BE>Здравствуйте, varenikAA, Вы писали:

BE>Если asp.net, то можно использовать https://www.hangfire.io/ или
BE>же Реализация фоновых задач в микрослужбах с помощью IHostedService и класса BackgroundService.

BE>Цикл с задержкой в дни выглядит как-то ненадежно.

Да ладно, прямо по твоей ссылке он и приведен же

IHostedService/BackgroundService только дает фоновую задачу, которая будет запущена инфраструктурой, но если ты в ней хочешь делать что-то, что будет срабатывать каждые Х минуто, то что? В примере по твоей ссылке как раз Task.Delay используется для этого случая.

Здравствуйте, BlackEric, Вы писали:

BE>Если asp.net, то можно использовать https://www.hangfire.io/ или
не, настольная прога WPF
BE>Цикл с задержкой в дни выглядит как-то ненадежно.
не обратил, внимание, там конечно сначала выполняется, потом задержка на 1 день. Чаще просто не нужно.

Здравствуйте, varenikAA, Вы писали:

AA>Как правильно организовать цикл с большой задержкой, есть ли разница?

А что, cron flavor в дотнет не завезли? Quartz, какой-нибудь

Здравствуйте, Miroff, Вы писали:

AA>>Как правильно организовать цикл с большой задержкой, есть ли разница?
M>А что, cron flavor в дотнет не завезли? Quartz, какой-нибудь

Quartz есть, но если все что тебе надо — это в паре мест периодически с примерно равными интервалами делать какую-то проверку, то его подключение выглядит избыточным. Он хорош когда нужны различные расписания, восстановления при перезапуске и подобные уже более сложные случаи.