As I have learnt over the years, at a certain stage of application development logging becomes critical. It is imperative during testing (especially with multiple, external testers) that they can report any problems or issues in the most efficient manner; this usually entails sending  a log file which the developer can use to locate and debug the bug.

VB.NET comes with its own ‘logging’ sub-system integrated into the language. It allows the developer to place entries into the log file at specified points in the code. These entry points are usually placed at strategic points, such as in the catch statement of a Try… Catch or at the end of a long process to indicate completion.

The logging sub-system of VB.NET resides under the My.Application.Log namespace. Under this namespace are several functions and concepts, that I will detail below, which will let you start logging in your own applications.

Several functions under this namespace allow you to write events to the log file. An ‘entry’ essentially, is composed of a string Message, a Severity Level and an Event ID.

The Message is a string that the developer specifies to appear in the log file. It should generally detail a stage in the code (e.g. “Starting update…”).

The Severity Level is used to determine how ‘critical’ the entry or exception is. This level is only used to help filter out critical events from the less critical ones. For example, an event of a failed update, “Update failed” should be classes at a error level, while an event such as “Starting update” should only be classed as an information level.

Other levels, such as a ‘critical’, are usually reserved for an error that causes the application to cease functioning.

The Event ID attribute is a way help index and identify the errors that may occur for correlation purposes. It is optional attribute when writing an event. It is usually reserved for error events as opposed to verbose events.

You can write events to the log by calling a function under the My.Application.Log namespace. The following code write an example event to the log;

My.Application.Log.WriteEntry("Starting to process function XYZ", TraceEventType.Verbose)

As noted above, the Event ID attribute is optional; it may be considered in-effective to index verbose level messages; reserving the event ID’s for error and critical level events.

When writing Errors to the log a slightly different and specialized function may be used. The WriteError function will write details of an ‘exception’ caught during a Try… Catch statement. It is invoked similar to the code example below;

Try
    Throw New Exception("A sample error exception")
Catch ex As Exception
     My.Application.Log.WriteException(ex, TraceEventType.Error, "Additional information or details")
End Try

Once the error exception is raised within the Try block, the WriteException event will write the exception details (ex) to the log. The same severity level option can be applied, as well as some additional notes to make debugging easier.

When the application closes, and the log file has been flushed to disk the file can be retrieved for analysis. By default it is placed in the user’s Roaming profile under a subdirectory relevant to your application name. To save some time, you can find out the direct path, and for example, show it in a message box, while running the program by executing the following line of code;

MsgBox(My.Application.Log.DefaultFileLogWriter.FullLogFileName)

As with any logging sub-system, some performance overhead (while extremely minimal) may be invoked. To help reduce this, it is possible to only log events that may be considered more relevant than others.

As discussed above the Severity Level can help rank events on a scale of severity, from Verbose to Critical. Similarly we can choose to only log events that we deem important on a release application, for example only events higher than the Informational level. We can choose programmatically as to which events should be included and which should not. The code below sets this level to log events only Information and above.

My.Application.Log.TraceSource.Switch.Level = SourceLevels.Information

The hierarchy of severity levels can be determined using the table below (source).

Logging becomes essential in larger, more complex programs with several teste. Hopefully the outline of the logging system above will make it simple to implement basic logging capabilities into your own application.

When developing certain types of programs, different methods of debugging may be required in order to effectively and efficiently debug.

For example, programs with a timer iterative functions with a small interval, programs intercepting Window (WndProc) messages, or even programs with multiple hooks to the keyboard or mouse. All these type of programs have something in common…. it’s a major pain in the backside to ‘step-through’ (by default F10 in Visual Studio) without it jumping to areas non-related to the area of interest.

It’s not until recently that I discovered the DebuggerStepThrough attribute as a question answer on Stack Overflow.

Essentially, the DebuggerStepThrough attribute belongs to the Systems.Diagnostics namespace, and can be placed before almost any block of code to indicate to the debugger that it should pass/skip the block in question.

Decleration of DebuggerStepThrough in C#;

[DebuggerStepThrough()]
private void AnExampleSub()
{
    // Annoying iterative code
}

Decleration of DebuggerStepThrough in VB.NET;

<DebuggerStepThrough()> _
Private Sub AnExampleSub()
      ' Annoying iterative code
End Sub()

During debugging step through, the debugger will not visit anywhere within the subs in the examples above.

Sometimes it may be required in your program that you need to alter the right click menu, otherwise known as context menu. With this following code snippit, you can completley yet simply change the entire menu to your own liking…

The theroy behind this code is that when a user right clicks on the program item, a ‘message’ is sent by the Windows UI to your program. Normally your program handles this message itself however we can ‘override’ this, and place our own actions there instead.

Private Const WMessageRightClickTaskbar As Integer = &H313
 
Protected Overloads Overrides Sub WndProc(ByRef m As Message)
 
        ' Check if the intercepted 'message' is a 'right click on taskbar'
        If m.Msg = WMessageRightClickTaskbar Then
 
            ' It is possible to change the action that occurs.
            ' In this case, a context menu is shown at the cursor position
            ContextMenuStrip1.Show(Cursor.Position)
 
            ' If you change the above event to something other
            ' than a context menu, remove the 'Exit Sub' below
            ' to restore the context menu and make it appear also.
            Exit Sub
 
        End If
 
        ' If it isnt, then handle it normally
        MyBase.WndProc(m)
 
End Sub

private const int WMessageRightClickTaskbar = 0x313;
 
protected override void WndProc(ref Message m)
{
 
    // Check if the intercepted 'message' is a 'right click on taskbar'
    if (m.Msg == WMessageRightClickTaskbar) {
 
        // It is possible to change the action that occurs.
        // In this case, a context menu is shown at the cursor position
        ContextMenuStrip1.Show(Cursor.Position);
 
        // If you change the above event to something other
        // than a context menu, remove the 'return' below
        // to restore the context menu and make it appear also.
        return;
 
       }
 
// If it isnt, then handle it normally
base.WndProc(m);
 
}