Logging (My.Application.Log) in VB.NET

Shadow | Code Snippits, Programming | Sunday, February 21st, 2010
Logging during an application refers to the tracing of internal code actions and functions, user actions, as well as any errors or exceptions that may arise.

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.

Log Events

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.

Writing Events to the Log

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.

Writing Errors to the Log

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.

So where does the log file end up?

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)

Level specific Logging

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).

SourceLevels ValueMessage severity required for output
CriticalCritical
ErrorCritical or Error
WarningCritical, Error, or Warning
InformationCritical, Error, Warning, or Information
VerboseCritical, Error, Warning, Information, or Verbose
ActivityTracingStart, Stop, Suspend, Resume, or Transfer
AllAll messages are allowed.
OffAll messages are blocked.

In Conclusion

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.

Skipping code during step-through debug Visual Basic, C# .NET

Shadow | Code Snippits, Programming | Saturday, February 13th, 2010

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.

Google Nexus One and Australia

Shadow | Hardware, Ideas & News, Internet | Saturday, January 23rd, 2010

Possibly one of the worst kept ‘launch’ secrets, Google announced the Nexus One back at the start of January, specifically the 5th.

Launched within the US, UK, Singapore and Hong Kong, customers were able to purchase a Nexus One. However, that left Australia and a plethora of other countries without access to the latest Google gadget.

More recently, there have been reports of a “2010 release date” for the Nexus One in Australia. Vodafone Hutchison Australia (VHA) (Vodafone and Three networks) have said “Details relating to Vodafone’s Australian launch of Google Nexus One will be announced in due course.”

This due course may be confirmed by some photos taken during a ‘dissection’ of the Nexus One…

The picture may not seem to reveal much at first, however in the lower left corner appears the ‘A-tick’, a certification of ACMA’s “Telecommunications/Radiocommunications Labelling”.

Being certified by ACMA hopefully indicates and confirms future sales in Australia.

In the mean-time the temptation to import grows, with numerous sites now offering the phone along with warranty with a slightly inflated price…

Bioshock 2: Steam Price in Australia

Shadow | Games, Steam | Wednesday, January 20th, 2010

Steam has opened Bioshock 2 for pre-order, to be released in just under three weeks.

BioShock 2 Pre-Purchase Now

JANUARY 19, 2010, 1:59 PM – VALVE – GENERAL ANNOUNCEMENT


BioShock 2 is now available for pre-purchase on Steam! Save 10% and earn an extra copy of BioShock free! If you already own BioShock then gift it to any of your friends!
Want to play with a few of your friends? The BioShock 2 Four Pack gives you four copies of BioShock 2 and four free copies of BioShock to give out to your friends!

However, the price for Australia in Steam appears to be substantially higher, $27 USD higher… Using the two links below show two different prices, and unfortunately unless you have a US billing address, you wont be able to use the US store page.

AUD Bioshock Page: http://store.steampowered.com/app/8859/?cc=au
USD Bioshock Page: http://store.steampowered.com/app/8859/?cc=us

Suggestions for getting the lower price range from illegal to legal, however probably the easiest legal method is to just get it gifted from someone in America then pay them back via PayPal.

Powered by WordPress
Theme by Roy Tanck, Modified by Shadow
Posts (RSS) and Comments (RSS) | Nearly Valid XHTML
16 queries. 0.508 seconds.