Recommend a C# Task Scheduling Library

http://quartznet.sourceforge.net/

"Quartz.NET is a port of very propular(sic!) open source Java job scheduling framework, Quartz."

PS: Word to the wise, don't try to just navigate to quartz.net when at work ;-)

Async CTP - Recommended approach for task scheduling

I'll take a shot at answering. ;)

Question 1: Can anyone reassure me that the implicit approach is a good idea? I see so many issues being introduced by ConfigureAwait(false) and explicit scheduling in legacy/third party code. How can I be sure my 'await-ridden' code is always running on the UI thread, for example?

The rules for ConfigureAwait(false) are pretty simple: use it if the rest of your method can be run on the threadpool, and don't use it if the rest of your method must run in a given context (e.g., UI context).

Generally speaking, ConfigureAwait(false) should be used by library code, and not by UI-layer code (including UI-type layers such as ViewModels in MVVM). If the method is partially-background-computation and partially-UI-updates, then it should be split into two methods.

Question 2: So, assuming we remove all TaskScheduler DI from our code and begin to use implicit scheduling, how do we then set the default task scheduler?

async/await does not normally use TaskScheduler; they use a "scheduling context" concept. This is actually SynchronizationContext.Current, and falls back to TaskScheduler.Current only if there is no SynchronizationContext. Substituting your own scheduler can therefore be done using SynchronizationContext.SetSynchronizationContext. You can read more about SynchronizationContext in this MSDN article on the subject.

The default scheduling context should be what you need almost all of the time, which means you don't need to mess with it. I only change it when doing unit tests, or for Console programs / Win32 services.

What about changing scheduler midway through a method, just before awaiting an expensive method, and then setting it back again afterward?

If you want to do an expensive operation (presumably on the threadpool), then await the result of TaskEx.Run.

If you want to change the scheduler for other reasons (e.g., concurrency), then await the result of TaskFactory.StartNew.

In both of these cases, the method (or delegate) is run on the other scheduler, and then the rest of the method resumes in its regular context.

Ideally, you want each async method to exist within a single execution context. If there are different parts of the method that need different contexts, then split them up into different methods. The only exception to this rule is ConfigureAwait(false), which allows a method to start on an arbitrary context and then revert to the threadpool context for the remainder of its execution. ConfigureAwait(false) should be considered an optimization (that's on by default for library code), not as a design philosophy.

Here's some points from my "Thread is Dead" talk that I think may help you with your design:

Follow the Task-Based Asynchronous Pattern guidelines.
As your code base becomes more asynchronous, it will become more functional in nature (as opposed to traditionally object-oriented). This is normal and should be embraced.
As your code base becomes more asynchronous, shared-memory concurrency gradually evolves to message-passing concurrency (i.e., ConcurrentExclusiveSchedulerPair is the new ReaderWriterLock).

Is there a good 3rd party Job Scheduling Library for .Net?

Quartz.Net. Open source, robust and very flexible. Supports load-balancing and much more.

Creating a custom and reliable task scheduler

I will use Quartz.NET and or Hangfire as scheduler solution.

https://www.quartz-scheduler.net

https://www.hangfire.io

Recommend a C# Task Scheduling Library