This project is read-only.
Welcome to the .Net Batch Scheduler.

This program can be installed on every single computer (physical or virtual) you administer. You can then schedule those computers to perform certain actions at specific times, and all controlled from a single database table. The program ships with 5 actions, but you can easily build more since the architecture is extensible.

This code demonstrates how to use MEF (Managed Extensibility Framework) and the Entity Framework (EF) 4.1 Code-First. I went through a lot of troubles trying to understand MEF and looking for a sensible sample that I could use to start with. If you are looking to get started with MEF and EF 4.1 I think my solution gives you a nice example that is easy to use and understand.

Also, this code is a fully working batch scheduler (The solution is called Backup Assurance since that is how I am using it, but it can be easily changed to do something completly different). Thanks MEF and EF 4.1!

The batch scheduler is more of an agent (or client) that connects to a database every 90 minutes (configurable) and determines which jobs it needs to run. Instead of creating timers for every single schedule, it only uses one timer to schedule the very next job. Once that jobs has executed, it looks for the next job to execute.

The database table specifies the name of the job to run, and that name is used to instantiate a .dll file that is responsible for performing that type of work (i.e. daily run an executable file, weekly verify backups were created, daily delete files older than 90 days, etc).

Running the Program:
Once you get the latest version of the code, the Solution File is hidden inside a folder called C:\code\Internal\TestConsole.
Once the project is open, it may be necessary for you to install MEF (I used MEF 3, Preview 2 found here on CodePlex) and the Entity Code Framework 4.1 (found through nuget in visual studio). I included the DLL files, but Entity Framwork may need additional pieces. Below are the instructions for installing Entity Framework 4.1:

To get the Entity Framework part working, simply go to ... Visual Studio >> Tools >> Extension Manager >> download NuGet . Once NuGet is installed, right click on the ExpDB project that is part of the code and select Add Library Package Reference. From that menu, find Entity Framework 4.1

At this point in time, you need to build the library.dll, since it is used by all the other projects. Once library.dll is built, you can build the rest of the DLL files.

Please note that my implementation of the batch scheduler is a Windows Service and it is NOT possible to run and debug the code as a windows service, so I had to create a separate project just to be able to run and test within the code.
The End Solution is the BackupAssurance.exe (the windows Service).
The Test Solution is ProjectStartTestHere (There run Program1.cs).
Before the program can run, you need to edit the app.config file in the two projects (just make the contents the same).

Once you get the code to compile, you need to schedule jobs. I wrote 5 different types of jobs that can be run.
impFileDelete - Deletes files older than 90 days
impFileRun - Runs a specified file
impFileSynch - Copies, Moves, or Synchronizes files
impMountDrive - Mounts or UnMounts a shared drive
impVerifyFileExists - Can see if a file was created the day prior (used to verify backups).

Looking at the project names, you will notice that some project names are prefixed with IMP or EXP. For my own sanity, and as I understood MEF, I differentiated when projects were Exporting functionality, or Importing key functionality.

Finishing the topic of projects, expDB has all the code to Create the database and database tables (thanks EF 4.1), and read, write, update the data in the Schedule and Audit tables.
ExpLogging is used in all module to write to a central log file -- it works through MEF composition, just like expDB.

However, the plugins do not use expDB to read/write data from the database. The Windows Service reads/writes all the data and it passes all the information that the plugin needs in the form of two objects. For flexibility, each action (or plugin that runs) can have its own specific data, which is entered into the table as XML, and passed to the plug-in as XML. This means that your plug-in can do almost anything, and you dont need to change the architecture.

I would like it if people can continue to improve on this project and make it better than I ever could. I will try to open the project so that anyone interested can contribute to it. One thing the project is missing is a web site to manage the data that is necessary to schedule the jobs. Currently, I update the table manually. Assumming the settings in app.config are correct to find a SQL Server database, the code will create the database and three tables that it needs. The code also creates 5 sample jobs for each plug-in type, so that you can see how the data layout.

Lastly, Credit to Andy Brummer for the ScheduleTimerBase.cs code.

I am probably forgetting some important information, so feel free to leave comments. I'll respond as soon as I am notified.

Last edited Jun 13, 2011 at 4:13 PM by s0ftimage, version 9