Do you utilize the Trace and Debug classes from the
System.Diagnostics namespace? Do you use a TextWriterTraceListener to log
your messages? Have you ever wondered why the TextWriterTraceListener
doesn't have the ability to roll over its logs at certain intervals?
I've developed a number of server-based applications
in which we employed the abilities of the System.Diagnostics classes to trace
certain application events. Whether its for debugging purposes or to
report unexpected events. Its easy enough to utilize the
TextWriterTraceListener to capture these messages and easily view them when
needed. Depending on what types of events your tracing and at what levels
your tracing at (see TraceSwitch), the trace log can get quite large
for a server-based application. I would find it very beneficial if
the TextWriterTraceListener would roll over its logfile at certain intervals,
say on a weekly, daily, or hourly basis. One of my mottos is: If it
doesn't exist, build it!
Here is a simple wrapper for the
TextWriterTraceListener that rolls over each day. I'm a little reluctant
in posting source code on a blog because I know there are some people who will
look at it and say, "Why on earth did you do it that way, you idiot!". But
that's allright. I can take the criticism. As a matter of fact,
that's why I'm posting this. For one, I want to share this with whomever
finds it useful and I also want someone to pick it apart and start a dialogue to
discuss if there's a better solution.
There is one question I hope the blog community
can help me come to a conclusion on. What happens when the log file rolls
over and another process is trying to write a trace message during the
rollover? Does that message get lost? Can I solve it through thread
synchronization? Is this even an issue?
Anyhow... here's the code for the
RollOverTextWriter:
using
System;
using System.Diagnostics;
using System.IO;
namespace
Corgan
{
public class RollOverTextWriter:
System.Diagnostics.TraceListener
{
string _fileName;
System.DateTime _currentDate;
System.IO.StreamWriter _traceWriter;
public
RollOverTextWriter(string
fileName)
{
// Pass in the path of the logfile (ie.
C:\Logs\MyAppLog.log)
// The logfile will actually
be created with a yyyymmdd format appended to the
filename
_fileName =
fileName;
_traceWriter =
new
StreamWriter(generateFilename(), true);
}
public override void Write(string value)
{
checkRollover();
_traceWriter.Write(value);
}
public override void WriteLine(string value)
{
checkRollover();
_traceWriter.WriteLine(value);
}
private string
generateFilename()
{
_currentDate =
System.DateTime.Today;
return
Path.Combine(Path.GetDirectoryName(_fileName),
Path.GetFileNameWithoutExtension(_fileName) + "_"
+
_currentDate.ToString("yyyymmdd") + Path.GetExtension(_fileName));
}
private void
checkRollover()
{
// If the date has changed, close the current stream and create a new
file for today's date
if
(_currentDate.CompareTo(System.DateTime.Today) !=
0)
{
_traceWriter.Close();
_traceWriter = new
StreamWriter(generateFilename(), true);
}
}
protected override void Dispose( bool disposing )
{
if( disposing
)
{
_traceWriter.Close();
}
}
}
}
Is this really necessary?
AT&T Wireless began offering its U.S. subscribers a service Thursday that uses mobile phones to identify the names and performers of more than 1 million popular songs.
To use the music recognition service, users dial a three-digit code, then must hold their mobile phone for about 15 seconds near a speaker playing the tune that they want to identify. Moments later, the service sends a text message to the users' mobile phone indicating the title of the song and the name of the recording artist.
The first search is free, each subsequent search costs 99 cents, plus standard airtime charges. Subscribers are not charged if the service fails to recognize a song. Read More…
Ok, I’ve been stumped on some songs before, but I’m not willing to pay .99 cents to figure it out. In due time, I always find what I’m looking for.
From a technologist standpoint, however, I’d be very interested in knowing how this process works. Think about it… you have to break down the different sound characteristics, in various parts of the song, and put those into bits to search on. On top of that, you have to deal with the potential of a crappy cell connection.
As part of the Visual Basic World Tour, Paul Vick and Jay Schmelzer of the Visual Basic team in Redmond are headlining next weeks Chicago .NET Users Group (CNUG) meeting. The meeting is April 21st at Microsoft’s Downers Grove office at 6:00PM. If you plan on attending, go here to register. We also plan on partaking in some beverages and good fun following the meeting. I'll put up the vote for the “after-party”. Would you prefer Champps, North Beach, or Hooters?
The May/June MSDN events have been announced (http://www.msdnevents.com). This series is focusing on Developer Productivity and looks to touch on various topics including a few of the Microsoft Application Blocks, IDE enhancements in Whidbey, XML features in “Yukon” and SQL Server 2000 Reporting Services. It looks like the MSDN Developer Champions have a full boat with this one. I’m looking forward to it.
If you’re in the Midwest region (IL, IN, WI), Jacob (blog) will host a .NET Pub Club if your event exceeds 100 active attendees, so pass the word and spend Jacob’s money!
Here’s the May/June synopsis:
Leveraging Application Blocks in your Application Development:Application blocks are reusable code components from Microsoft for common programming tasks that encapsulate best practices and real-world requirements. We will examine three of these: the Exception Management Application Block that logs exception information to the Windows Event Log; the Configuration Management Application Block that manages configuration data and the Updater Application Blocks that implements a pull-model self-updating capability.
Rapid Application Development features coming in Visual Studio .NET “Whidbey”:In this session, we will look at improvements to the Whidbey IDE (integrated development environment), the new code snippet - IntelliTask- feature, namespace shortcuts, and language enhancements.
XML, XQuery and CLR Integration coming in SQL Server “Yukon”:The next major version of Microsoft SQL Server, codenamed “Yukon”, will extend its XML capabilities with a native, full-fledged XML data type, support for the XML Query and XML Schema Definition language standards, and the graphical XQuery Designer tool. We'll demonstrate how Yukon’s ability to host the .NET Framework common language runtime will enable stored procedures, triggers and user-defined functions to be written in Visual Basic .NET and C#, and then run in its memory managed, type-safe and secure execution environment.
Introduction to SQL Server 2000 Reporting Services: . In this session, you’ll see how the Reporting Services integrates with Visual Studio .NET to create and customize reports, and lastly, manage and schedule delivery of updated reports in the Report Manager.