There are three classes covered by this chapter:     Process, EventLog, PerformanceCounter

There is a namespace common to all three:     System.Diagnostics.

The  "Process"  Class

You use the  Process  Class to get information about other things running on the local machine or on a remote machine,  and to start and stop routines on the local machine.

Starting and stopping processes

Methods of the  Process  Class for controlling processes

• CloseMainWindow().   For processes  with  a Windows message loop
• GetProcessById().   Note:  singular.
• GetProcesses().   Plural.
• GetProcessesByName().   Plural.
• Kill().   For processes  without  a Windows loop
• Start().   Uses  StartInfo  to know what to do.
• WaitForExit().   Returns control only after the program has really gone away.
• WaitForInputIdle().   Returns control only when the program has finished its initialization.   You need this if you're going to ask the program for something—you want to let it prepare.

Properties of the  Process  Class

• EnableRaisingEvents.   It indicates whether  Exited  should be raised.   The problem is,  its default value is  false.
• ExitCode  
• ExitTime  
• HasExited.   A property,  remember,  not an Event.
• Id  
• StartInfo.   Information to pass to the  Start()  method.   There is one required member:
  • FileName.   Not necessarily an executable;  can be a file name with a registered file type,  as  Foo.doc  is registered to Microsoft Word.

Events of the  Process  Class

• Exited.   The Event raised when the process has exited.   See the  EnableRaisingEvents  property.

There is an example of using these in Kalani,  on pages 946-948.

Getting information about Processes

Kalani has a long list of properties of  Processes on page 949.   Interesting,  but not worth memorizing.

Event Logs

Event Logs are persistent lists of messages put out by programs as they run.   They can be easily examined by system tools,  on this machine or another connected to it,  and they can be read from code.   Kalani doesn't mention that they can also contain data other than text strings.

The easiest way to see these logs is through the .NET IDE,  under Server Explorer.   You can also see them using Control Panel / Administrative Tools / Event Viewer.

There are three types of logs available by default on your machine:  Application,  Security,  and System.   The Security log is read-only.

The reason for the presence of these several pages in Kalani,  or for any involved questions on the test,  is puzzling.   It is perfectly easy to create an event log source and use it in your program to write to a log—even to deploy it on a target machine—by using the IDE's tools.   Specifically,  you drag the EventLog you want to use from Server Explorer,  give it a source,  and write to it.   However,  we must look at what Kalani has written.

You can write logs on your own machine.   You can read and write logs on remote machines,  but you cannot receive notifications—i.e.,  events—for log entries written there.

Kalani ducks the issue of creating an entirely new log—that is,  a log in addition to Application,  Security,  and System.

"Source"

Each log has a source.   "If you write to an event log,  you must specify or create an event Source.   The Source registers your application with the event log as a valid source of entries.   You can only use the Source to write to one log at a time.   The Source can be any random string,  but the name must be distinct from other sources on the computer.   It is common for the source to be the name of the application or another identifying string.   An attempt to create a duplicated Source value throws an exception.   However,  a single event log can be associated with multiple sources.... A source is required only for writing to logs" [not for reading them]     (Help: "EventLog Class, about")
"If a source has already been mapped to a log and you remap it to a new log, you must reboot the computer for the changes to take effect."     (Help: "EventLog.Source Property")

Don't be misled by the .NET IDE!   If I open Server Explorer on my machine,  one of the nodes I find is labelled  "Event Logs".   If I expand that node,  I find three subnodes:  Application,  Security,  and System.   If I expand the Application node,  I will get,  on my machine,  a long list beginning

• ଀   Event Logs
  • ଀   Application
    • ଀   Application Error
    • ଀   Application Hang
    • ଀   ASP.NET 1.1.4322.0
    • ଀   ccEvtMgr

                    etc.,  etc.,  etc.

  • ଀   Security
  • ଀   System

Writing to a log from code

It is easy to write to a log from code.   Don't be fooled by all the code listed in this chapter.   Here's what you have to do:

• Start a windows app.
• At the top of the routine, add  using System.Diagnostics;
• Drag the "Application Log" entry from Server Explorer onto your form.   (No,  you can't drag a source—that is,  an entry under  "Application Log".   You have to drag  "Application Log"  itself onto your form.)
• You now have,  in the component tray below your form's desktop, an entry reading  "eventLog1".   Select it.
• In the properties window for  "eventLog1",  set some value for  "Source".
• From the IDE's Toolbox,  drag a Button onto the desktop.
• Double-click this button,  and in its click event,  add

        eventLog1.WriteEntry("Hello, log");

  or,  if you want a log entry type,

        eventLog1.WriteEntry("Hello, log, here's some info", 
           EventLogEntryType.Information);

• Run the app and click the button.   This will create the Event Source,  if it is not already created,  and it will write the entry into the log.
• In Server Explorer,  open the  "Application Log"  node,  and find the source whose value you entered for the log's  "Source"  property.
• Right-click that source node,  choose  "Refresh",  and your message will appear in a properties window.

Details

Some methods of the  EventLog  Class:

• CreateEventSource()
• Delete()
• DeleteEventSource()
• Exists()
• SourceExists()
• WriteEntry()

Some properties of the  EventLog  Class:

• EnableRaisingEvents
• Entries.   The collection holding the entries in a specified log.
• Source

The  EventLogEntryType  Enumeration.   (An optional descriptor for each entry written to a log):

• Error
• FailureAudit
• Information
• SuccessAudit
• Warning

Event Log Annoyances

• You have to set the  EnableRaisingEvents  property to  true  before you can get notification of event log entries.   And its default setting is  false.
• Only the first eight (8) characters of a log's name are significant.   I am not making this up.
• "You can use the EventLog class to create a custom event log on a local or remote computer."   (MSDN:  "Creating and Removing Custom Event Logs")
• But you can't get notifications about log entries written on remote machines,  though you can read their logs.   (Kalani, page 961; example, p. 963)
• There must be five (5) seconds between log entry writes,  or you might not get notification.   (Kalani, box, p. 961)
• "If a source has already been mapped to a log and you remap it to a new log,  you must reboot the computer for the changes to take effect."   (Help: "EventLog.DeleteEventSource Method (String)"

Performance Counters

Performance counters are numerical values put out by a program for diagnostic purposes.   They can be written and read from code,  and they can be read and their changes over time graphed by system tools such as  perfmon.exe.

Terms and Annoyances

Category.   Performance counters are grouped into categories.   You can only add a performance counter to a new Category when you create it.   You cannot add performance counters to an existing Category.    (Kalani, box, p. 970)

Instance,  as in "Instance counter".   Pay attention:  this is a really misleading use of object-oriented terminology,  even by Microsoft standards:

An "instance counter" is not an instance of a performance counter,  as every other object of a class would lead you to expect.   An "instance counter" is a counter for an instance of something else.   For example,  if you have a number of copies of the same routine running—say,  several copies of Notepad—they all might have their own set of counters.   That is,  each  instance  of Notepad would have its own set of  "instance counters".   Clear?    (Kalani, p. 965)

Sampling.   The term for reading the values of performance counters.   (Kalani, p. 967)

Publishing.   The term for setting values into performance counters.   You can only read, not set, counters on a remote machine.   (Kalani, p. 969)

perfmon.exe.   A system tool for monitoring these counters.   You can start it from  Start / Run  or from  Windows Control Panel / Administrative Tools.

RawValue.   The value for an uncalculated number set for a performance counter.

BaseValue.   Another value set for a performance counter,  this one used in calculating values to display in the monitor tool.

Some members in the Performance Counter Class

• CategoryName
• CounterName
• Decrement().   By 1.
• Increment().   By 1.
• IncrementBy()   By the stated amount,  which might be negative.
• InstanceName
• MachineName
• NextSample.   Returns a  CounterSample  object containing such things as
  • RawValue
  • BaseValue
  • TimeStamp
  • SystemFrequency
• NextValue.   The current calculated value.   A  float.
• RawValue.   The uncalculated value for a Performance Counter.

Reading a Performance Counter from code

Here's what you have to do:

• Start a Windows app.
• At the top of the routine, add  using System.Diagnostics;
• Open the Server Explorer and drag the Performance Counter of your choice onto your Form's desktop.   You now have,  in the component tray below your form's desktop,  an entry reading  performanceCounter1.
• Add a textbox and a button to your Form.
• Double-click the button,  and for its click event,  add code like

        CounterSample cs = performanceCounter1.NextSample();
        textBox1.Text = cs.RawValue.ToString();

• Run the app and click the button.   The number probably won't mean anything to you,  but what do you want?

There is a rather complex example of reading Performance Counters,  including instance counters,  at the end of this chapter.   (Kalani, pp. 980-982)     This is the only place where Kalani really addresses the problem of instance counters.

A source of further information on Performance Counters is Burton.   (Burton, pp. 727-757)

Free Advice

Kalani ends this chapter with a few pages on good performance practice—i.e.,  code that produces fast-running programs.   I won't repeat the list here,  as most of it is obvious.   For the entry labelled "Use auto-generated commands",  though,  he seems to have omitted the word "don't".   (Incidentally,  this is the only mention anywhere in Kalani of the  CommandBuilder  class.   Remember  CommandBuilder?)

A few items on this list pop up in the sample test questions.   I can't remember if any of them occurred on the real test.

(In general,  Kalani is quite free from this sort of mush.   This section and the one on  "Logo Programs"  at the end of chapter 13 are about the only examples I can remember.)

The  ListView  Control

Incidentally,  notice the frequent use of the  ListView  control in this chapter.   There are examples on pages 952,  962,  968,  978,  and 980.   What are the differences between a  ListView  control and a DataGrid?   Well,  for one thing,  the columns in a  ListView  seem to be of variable width by default.  

    Test 1:  question  57  (page 383;  answer:  page 399).

    Test 2:  none.

(The "short Kalani" text is listed here.)