create and Control Windows Services--Add File-Moni
2024-07-21 02:21:29
供稿：網友
now that all the necessary architecture is in place, you can add some functionality to the service. as an example, i'll show you how to build a file-monitoring service that monitors the local file system and notes important activity by presenting the data with a custom performance counter.
the servicebase class provides a couple properties all services should implement. servicename is the name your service uses to identify itself to the system and to applications that want to start it programmatically. for this example, the servicename property is "file monitor service." another property is canpauseandcontinue—set this to true so your service can support pause and continue functionality.
the onstart() function performs the necessary initialization to start file monitoring as well as create the custom performance counters on the local system if they haven't been created already. the .net framework monitors local file system changes by implementing the filesystemwatcher class, defined in the system.io namespace, which allows you to specify handlers for file change notification events. in this case, you're interested in files that are created, changed, deleted, or renamed. because you want to monitor file changes only on the local file system, you must enumerate all the defined drives and create a filesystemwatcher object only on fixed drives. but the .net framework (as of this writing) doesn't contain any special functions to do this. so you must invoke the getdrivetype() api call defined in kernel32.dll on each drive in the array created from the call to getlogicaldrives(). you can create a small class called platforminvokekernel32 to wrap the api and call getdrivetype() easily:
public class platforminvokekernel32
{
[sysimport(dll="kernel32", charset=system.runtime.interopservices.charset.auto)]
public static extern int
getdrivetype (string lprootpathname);
}
this code simply forwards all calls using platforminvokekernel32.getdrivetype() to the associated function in kernel32.dll. to get the drive type for each drive in the array, check the value returned from the call to the enumerated type win from the microsoft.win32.interop namespace:
string[] drives = environment.getlogicaldrives();
// create filesystem watchers for
// local fixed drives
foreach (string curdrive in drives )
{
if (
platforminvokekernel32.getdrivetype
(curdrive) == win.drive_fixed)
{
// create a filesystemwatcher
}
}
now that you've created the filesystemwatcher objects, you must implement the event handlers for the four file notification events: creating, changing, deleting, and renaming files. you'll create performance counters that convey information to the user visually—one for each event. for more information on file notification event handlers and creating performance counters, download the code that accompanies this article. to create a performance counter, use the performancecounter class specified in the system.diagnostics namespace. when you call the file change event handler, it simply increments the proper performance counter by 1:
private void onfilechanged(object source, filesystemeventargs e)
{
filechangecounter.incrementby(1);
}
the servicebase class also enables the service designer to create custom commands that the service control manager can send to the service. this is an overridden but optional function named oncustomcommand(), which i mentioned earlier. it contains a single parameter, an integer, that signifies the custom command to run. one thing you need to keep in mind: the command integer must be a value between 128 and 256; all other values are reserved by the system. for the file-monitoring service you're building, you create four custom commands to reset the counter data for each of the performance counters back to zero. the performancecounter class doesn't support a "reset" function specifically, but you can accomplish this easily by decrementing the counter by its current value (see listing 1).
