Windows Service vs Service Worker

Witam.
Czy zrobienie czegoś co by działało w tle na systemie Windows kończy się tylko na wyborze pomiędzy 20sto letnim Windows Service, a najnowszym .NET (Core) Service Worker? Tego drugiego zaleca się używać do jakiegoś backendu, a czy bez tego backendu zadziała jak zwykła usługa windows? Tutaj Microsoft pokazuje jak to skonfigurować. Nie mam za dużego doświadczenia w tego typu projektach i martwię się czy coś mnie może zaskoczyć, bo szczerze mówiąc nie chce wracać do .NET Framework i Windows Service. Czy konfiguracja wywołania jakiegoś zadania kończy się na Task.Delay(), da się wcisnąć w to jakiś timer np. Quartz? W tego typu usługach nie ma metod Start(), Stop(), nawet jakby chciał skonfigurować Quartza to przecież metoda ExecuteAsync będzie się w kółko wywoływać (po to jest ten delay na końcu).

Projekt będzie synchronizował dane pomiędzy system e-commerce, a Comarch Optima - kontrahentów, użytkowników, cennika, stanów magazynowych, kategorii, zamówień, aktualizacja statusów zamówień. Dobrze by było, aby synchronizacja zamówień, kontrahentów, cenników i stanów odbywała się asynchronicznie, aby nie trzeba było czekać, aż jedno skończy.

Czy to jest możliwe za pomocą Service Worker?

ExecuteAsync z klasy pochodnej BackgroundService wykonuje się tylko jeden raz.
W podanym przykładzie została napisana pętla, ale nie trzeba jej tam robić. Można tam napisać wywołanie Quartz.
Warto zastanowić się nad tym czy implementacja podobna do tej przedstawionej w linku nie będzie tą wystarczającą.

Odpowiadając na pierwsze pytanie: jest to dobry wybór jeśli chcemy stworzyć usługę Windows.

No faktycznie jest pętla. Czyli jeśli wywalę while (!stoppingToken.IsCancellationRequested) to wywoła się tylko raz i tam mogę wrzucić konfigurację Quartza? Czy ten CancellationToken coś mi daje? W sensie, biorąc pod uwagę problem jaki próbuje rozwiązać.

Nie wiem jakie masz wymagania odnośnie tego background joba, ale popatrz na Hangfire. Jeżeli potrzebujesz czegoś więcej niż tylko przenieś dane z A do B to Hangfire będzie twoim sprzymierzeńcem.

A tak w sumie - czy musi to być usługa? Nie możesz dodać jakiejś apki do autostartu, a potem - jak się odpali, to zrzucić do tray'a?

No niby mogę, ale apka uruchomi się dopiero jak ktoś się zaloguje, a to będzie na serwerze gdzie mało kto zagląda.

@markone_dev: Wydaje mi się, że do mojego projektu Hangfire to troszkę za dużo. Kiedyś musiałem zdecydować jakiego schedulera używać i, jeśli dobrze pamiętam, to Hangfire miał problem ze zwracaniem wartości, a potrzebowałem tego do jednego projektu.

Spoko. Dlatego napisałem żebyś się nim zainteresował bo może akurat będziesz miał use case'y gdzie by się sprawdził. Jeśli nie masz to tak jak piszesz, nie ma co go pchać tam na siłę :)

Osobiście nie wiem co jest złego w serwisach i jeśli miałbym implementować coś do działa na windowsie w tle to rozważałbym je jako opcję.
Do serwisów polecam bibliotekę Topshelf - https://topshelf.readthedocs.io/
Bardzo łatwa konfiguracja

Kolejną opcją, jest task scheduler - można konfigurować zadania tak aby nie wymagały żadnego zalogowania się.

@var problem polega na tym, że chce mieć już jak najmniej wspólnego z .NET Framework. Jeśli rozwiązanie z Service Worker nie spełniło by moich oczekiwań/wymagań to bym był zmuszony użyć Windows Service. A się okazuje, że to świetne rozwiązanie, oprócz tego, że to .NET 6, to jeszcze ma build-in dependency injection, a debugowanie działa bez topshelf. Dodatkowo to co wrzucił @gosc_z_pytaniem na temat Quartza i konfiguracji w Program.cs dodatkowo ułatwiło konfiguracje całego projektu w kwestii niestandardowych ustawień wywołania konkretnych zadań.