IScheduler Resolve Issue with Quartz.Net & Unity

Today I was creating a job scheduler using Windows service, Quartz.Net and Unity. It is a killer combination and provides graceful application setup for job scheduler. Not to mention, it works like a charm. But, unfortunately I came across a painful issue while resolving Quartz’s IScheduler interface. For several hours, I looked all over the internet for the solution but I couldn’t find any solution. Hence, I am writing this post.

Just to give you a quick background of application environment, I was using following framework and packages in my service. I installed them from Nuget Packge Manager.

  1. .NET Framework 4.5.2
  2. Quartz.Net 2.3.3
  3. Quartz.Unity 1.4.2
  4. Unity 4.0.1

In order for dependency injection to work in the scheduler applications built with Quartz, you have to resolve IScheduler using Unity. You can not directly instantiate StdSchedulerFactory() and GetScheduler (see here for normal set up). I wouldn’t go into much details about what each line of code does but below is the code snippet one should write.


var scheduler = Container.Resolve<IScheduler>();


At the line #2 program fails. Briefly, it says:

Resolution of the dependency failed, type = “Quartz.ISchedulerFactory”, name = “”(none)”.

The issue looks like the picture below:



Why this issue, what I did wrong and how to resolve this?

I looked through what AddNewExtension is doing. Tried to manually register Scheduler Factory. Tried many things. Then, I looked through each and every package description, their versions & dependencies on Nuget website. And then when I looked at different versions available for dependent assemblies. Finally, I found the culprit assemblies:

  1. Common.Logging
  2. Common.Logging.Core

I found that the version I had in references was 3.0.0 for both the assemblies. I updated these assemblies with the latest version (3.3.1). Bingo! the application worked.

So what happened? The latest package of Quartz.Net is compiled with old version (3.0.0) of Common.Logging and Common.Logging.Core. When I installed Quartz.Net the old version of these assemblies ended up in my references.

Unfortunately, the exception didn’t mention anything about Common.Logging. One can argue that using another DI framework like Castle Windsor or drop Quartz from solution could be easier. But you never know when all of the sudden you would encounter such unrelated problem.

Yet another day. Hope this post will help.



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s