Also, have you enabled logging with log4net in EPiServerLog.config? It might tell you more :)
I've noticed that your class name is still PreviewThumbnail
which I imagine is the name of the scheduled job that you were first trying to create. Is it possible that your solution still contains the original PreviewThumbnail (in a different namespace?) and EPiServer still has that Scheduled job registered and is trying to run it. You can check which plugins are enabled - disabled in the Admin > Config > Plug-in Manager.
As for your original issue: along with ensuring that there are no HttpContext.Current calls in your scheduled job, there are also other types of calls that will fail as the EPiServer scheduled job is a windows service and runs outside of the asp.net context. For example trying to access config variables (using ConfigurationManager) will fail as the service will look for an app.config file in C:\Program Files\EPiServer\Shared\Services\Scheduler Service and not the one you'd expect from your web root.
In these cases the EPiServer API exposes a method that will allow you to access what you would normally access through a standard .net API, but instead returns data from the correct EPiServer web context.
I suggest you remove your class, restart the application, and then create a new class with a new name and move your code to it. On every start of the application the assemblies will be checked for classes matching the plugin attribute. Any found will be added to the database, but I don't think anything's ever removed.
This seems to cause the scheduler to try to start jobs (load types) that are nonexisting, causing the null reference (which happens outside the exeucte method which is why you can never catch it). How these invalid classes get connected to the named scheduled jobs visible I could never understand, but nevertheless it seems to be the case.
By removing your class you give it a chance to clean up, and by changing the name perhaps it will load the correct type. If that doesn't work, check the tblPlugin and tblScheduledTask tables (or whatever they're called) and remove the rows that refer to the old removed classes (take a DB backup first!).
The version is 5.2.375.236. I've tried to enable logging and debug the scheduler, but it didn't really give me any more clues.
Mark, I wasn't aware that accessing config variables would make the service fail, that's a good thing to know! What about calls to EPiServer.Web.Hosting.VirtualPathHandler.GetProvider(), will that also fail?
Magnus, you're absolutely right about nothing being removed. After cleaning up my database and changing the class name, the code above worked as a charm! Too bad there's no easier way than doing it directly in the database though.
You guys are great, thanks for helping me out!
You can still get at the config variables in your scheduled job, you just have to use the EPiServer API (EPiServer.Configuration.EPiServerSection.Instance for example) to return them.
As my wise colleague David said;
"If the EPiServer API exposes a method of doing something that you could use .NET directly for, then use the EPiServer method as they probably had a reason for doing it".
If you are multiple developers that run against the same test database, this can occur as well if not everyone has updated their code. For instance, developer 1 makes a scheduled job (which is stored in the test database). Developer 2's computer has the scheduler service active which tries to run this job but of course doesn't have the correct code = fail.
Some easy suggestions for solutions are:
-Use local databases instead
-Disable the scheduler on all development machines (its a setting in web.config under site settings)
-Disable the scheduler service and set it to start as manual instead. When you need it you can always start it.
Note to EPiServer: Adding machine name to the error message would help.
I know this is an old question, but for anyone who stumbles on this problem;
The sceduled job log says "FAILED Object reference not set to an instance of an object." when running via the scheduler but not when running from the interface.
This may be because something is wrong with the schedulers reference to the site and the job. Maybe as Daniel says it's because you are accessing the database from multiple environments, like developers in a team with different code.
For example, if you add logging to the starting point of the job and nothing is logged it's obvious that there's nothing wrong in the job itself but with the scheduler.
There is a simple solution:
Cheers
Fredrik
Hi,
I see I'm not the only one having this problem, but so far none of the other solutions in this forum has worked for me. I started out creating a quite complex scheduled job, which worked fine when running it manually. It did not, however, work when I tried to run it automatically. The error I got each time was: "Object reference not set to an instance of an object."
After a bit too much debuging, I've surrendered and decided to create a new scheduled job. I now have this code and it still fails when I try to start it automatically:
Extra info:
- I'm the only dev working on this, so there's no chance in hell that someone else is trying to run the job at the same time.
- The site is running on one computer only.
Things I've done to try and fix this:
- Restart the EPiServer Scheduler Service
- Run the built-in scheduled jobs automatically (they all run without problems)
- Delete the scheduled job and recreate it
- Made sure the code above has no references to HttpContext.Current
- Kick my computer
Any ideas, however crazy, would be highly appreciated!