IT Guy

Introduction

Task Scheduler is the Windows service that schedules and automatically starts programs. Windows Explorer presents a user interface to the service when you browse the %WINDIR%\TASKS folder, typically from the shortcut in the control panel. From the command line, the schtasks command and the old at command do the same. Programmers have a well-documented COM interface, but the .NET framework does not offer any wrapper for it. The present library provides that .NET wrapper.

Note: Since this library was created, Microsoft has introduced a new task scheduler (Task Scheduler 2.0) for Windows Vista. This library is a wrapper for the Task Scheduler 1.0 interface, which is still available in Vista and is compatible with Windows XP, Windows Server 2003 and Windows 2000.

The library is an expanded version of a package written by CodeProject.com member David Hall. See his article. In the original work, David demonstrated how a collection of COM interfaces could be tamed into a logical class library in the .NET style. This new version offers many improvements, including the elimination of COM memory leaks. Fixing the memory leak problem required the adoption of an incompatible class hierarchy, but, for clients in transition, the original hierarchy remains available as a kind of differently organized view of the same objects. It is deprecated, however, because of the leaks. A later section on compatibility gives more detail.

Documentation is contained in an HTML help file, MSDN-style, which is downloaded along with the library. The documentation is intended to be self-contained and sufficient for any client to use the library. MSDN documents the COM interface on which the library is based. It is worth consulting when the library's documentation lacks.

The second download contains the source code for the library and for a C# test application that also serves as sample code. The test application is a trivial command line interpreter that operates on scheduled tasks. It can easily be modified to insert whatever tests you may want to make.

This article introduces the library's class hierarchy and also describes some of the changes that were made from the original version.

Classes

Sample Code

Changes from Version 1

Compatibility with Version 1

Changes in Internals

History

Classes

The complete class hierarchy is illustrated by the following diagram, drawn to the standard David Hall set in his article. The abstract class StartableTrigger makes the hierarchy a bit more complicated than I'd like, but is included for completeness. For most purposes, clients can more simply consider the various concrete trigger classes as direct subclasses of Trigger .

ScheduledTasks

A ScheduledTasks object represents the Scheduled Tasks folder on a particular computer. This may be either the local machine or a named machine on the network to which the caller has administrative privileges. In the machine's Scheduled Tasks folder, Windows keeps information for each scheduled task in a file with a *.job extension. All tasks in the folder are said to be "scheduled," regardless of whether they will actually ever run.

Collapse | Copy Code

// Get a ScheduledTasks object for the computer named "DALLAS" ScheduledTasks st = new ScheduledTasks(@"\\DALLAS");

You use a ScheduledTasks object to access the individual tasks. Each task has a name, the same as its file name without the extension. From the ScheduledTasks object you can obtain the names of all the tasks currently scheduled. There are methods to create, open and delete tasks, all of which use the task's name.

Collapse | Copy Code

// Get an array of all the task names string[] taskNames = st.GetTaskNames();

A ScheduledTasks object holds a COM interface. When you are finished using the object, call its Dispose()method to release the COM interface.

Collapse | Copy Code

// Dispose the ScheduledTasks object to release COM resources. st.Dispose();

Task

A Task object represents an individual scheduled task that is open for access. Its properties determine what application the task runs and the various other items you can see in the Explorer user interface. One such property is its TriggerList, another class discussed below. After creating a Task or opening and modifying a Task, it must be saved to record the new state in its file. You can save it under its current name or you can provide a new name. Saving with a new name is like "Save As" in a Windows application: the open Task remains associated with the new name. There is no public constructor for Task. A Task can only be created by a ScheduledTasks object using itsOpen() or Create() methods.

Collapse | Copy Code

// Open a task named "foo" from the local computer's scheduled tasks ScheduledTasks st = new ScheduledTasks(); Task t = st.OpenTask("foo");

A Task retains COM interfaces. When you are finished using a Task, call its Close() method to release the interfaces.

Collapse | Copy Code

// Close the Task object to release COM resources. t.Close();

TriggerList

A TriggerList is a collection of Trigger objects. Every Task has a TriggerList that can be obtained from a get-only property. There are no public constructors for TriggerList. Every TriggerList is associated with aTask and is constructed along with the Task, so a TriggerList can only be obtained from its Task object.

Collapse | Copy Code

// Get the triggers for the local task "foo". ScheduledTasks st = new ScheduledTasks(); Task t = st.OpenTask("foo"); TriggerList tl = t.Triggers;

A TriggerList becomes invalidated when its task is closed. (Further access causes an error.)

Trigger

Triggers are conditions which, when satisfied, cause a task to run. In the Explorer UI, triggers are called "schedules." There are several types of triggers and different data is appropriate for different types. Thus, theTrigger class is actually an abstract class from which an assortment of concrete classes is derived. Each concreteTrigger class has unique constructors that specify the particular type of condition it represents. To set a new trigger for a task, construct a Trigger of the appropriate variety and then add it to the task's TriggerList .

Collapse | Copy Code

// Add a trigger to run task "foo" at 4:30 pm every day Trigger tg = new DailyTrigger(16, 30);  // hour and minute ScheduledTasks st = new ScheduledTasks(); Task t = st.OpenTask("foo"); t.Triggers.Add(tg); t.Save();

When a new Trigger is created, it is not associated with any Task or TriggerList and is said to be unbound. An unbound Trigger does not hold any COM resources and has no special usage protocol. When a Trigger is added to a TriggerList, it is then said to be bound and it remains so unless it is removed from that collection. A boundTrigger holds a COM interface. The COM interface is released when the corresponding Task is closed, so no special care is required on the part of the client. The distinction between unbound and bound Triggers rarely comes up in client code, but the following points are the essence:

A Trigger can only be in one TriggerList at a time. Therefore a bound Trigger can�t be added or assigned to a TriggerList because it is already in one. To put the same Trigger in a secondTriggerList, use Clone() to create an unbound copy.
A bound Trigger object can�t be used after its task is closed. (Further access causes an error.)

For detail click here