Test-running SharePoint timer job using console application

SharePoint timer jobs can be inconveniet to debug as you have to attach debugger to OWSTIMER.EXE after deployment. Often you must restart this process so it starts using latest version of your assemblies. When building something complex we want to run our code many times to see how it works and if there are errors. But deploying, attaching to debugger and so on – is there easier way to run timer job? Yes, there is!

NB! The ideas introduced here work in most cases but not always. You may also find situations where you have no other option than deploying solution and attaching debugger to SharePoint timer service.

Background

Software architects call some code as core functionalities and some code is called container specifics. What it means? Core functionalities are those important things that system does: calculate something, import something, send something and so on – practically business logic. This code is always invoked by other code that makes up web or console application, Windows service or some thing that can be run. The code that invokes business procedures runs in context of some application or container and therefore it is specific to its application or container.

If we want to make business procedures reusable and testable we have to break all dependencies with specific container where business processes may be hosted. Of course, we make running of business code a little bit more complex but we can run same business procedures in more than one container.

The idea begind our solution is simple: move core functionality to separate library and then use console application to run code in this library.

Solution

As often we start with timer job that has already code inside it that does real work then let’s see how we get moving from here:

1. Add new class library project to your solution
2. Move all functional code from timer job to new class library
3. Modify code in class library the way it has no dependencies with timer job
4. Make timer job call code in class library
5. Add new console application to solution
6. Add reference to class library project
7. Make console application call code in class library

Now you can run your timer job code in console application without any deployments and debugger attaching.

If you don’t want to move code to other library you can make code arrangements described above in timer job project and then reference this project in console application. If your breakpoints in timer job are not hit when running console application you can also link timer job related files to console application.

Problems you may face

Every coin has two sides and this solution is not exception. You achieve simplicity by introducing new problems you must be aware of.

• Console application and timer job are using different user accounts and therefore you must also test your timer job before saying that task is completed.
• It’s possible you find situations where you must run code in timer job for different reasons and you cannot use this solution.
• You may run into different issues when running code in console application. Before any changes to SharePoint farm and servers configuration make sure you know exactly what is the problem and how to solve it the way that you don’t set whole farm in danger.

This far I have ran into issues only few times and issues have been simple ones. So I think this solution should work also for you in most situations.