Log4net’s SmtpAppender with multiple email addresses

Log4net is a popular logging framework, and amongst the various logging “appenders” it includes one for sending emails – the SmtpAppender. The documentation for the SmtpAppender’s To property says it contains a semicolon-delimited list of email addresses.

However if you try to do that, you won’t see any emails being sent. Add the following to your app.config file to enable log4net’s debug logging:

<appSettings>

<add key\="log4net.Internal.Debug" value\="true" />

</appSettings>

<system.diagnostics>

<trace autoflush=“true”>

<listeners>

<add name\="textWriterTraceListener"

 type\="System.Diagnostics.TextWriterTraceListener"

 initializeData\="C:\\\\tmp\\\\log4net.txt" />

</listeners\>

</trace>

</system.diagnostics>

You’ll then see this internal error message in the log4net.txt file:

System.FormatException: The specified string is not in the form required for an e-mail address. at System.Net.Mime.MailBnfHelper.ReadMailAddress(String data, Int32& offset, String& displayName) at System.Net.Mail.MailAddressCollection.ParseValue(String addresses) at log4net.Appender.SmtpAppender.SendEmail(String messageBody) at log4net.Appender.SmtpAppender.SendBuffer(LoggingEvent[] events)

This shows that the SmtpAppender is leveraging the .NET Framework’s System.Net.Mail.MailAddressCollection class. The ParseValue method is not public, but Add(string) is, and if you scroll down to the remarks, you’ll see the following text:

If multiple e-mail addresses separated with a semicolon character (“;”) are passed in the addresses parameter. a FormatException exception is raised.

So it turns out log4net’s documentation is misleading, or at least out of date. Change your email addresses to use the comma and everything comes good again.

Drought breaks..

I’m pleased to report that it appears the biscuit drought has broken. We’re seeing good falls of assorted creams as well as the good old family assorted again.

That is a relief!

One of the nice things about my current workplace – they provide tea, coffee, Milo (but not Bonox!) and usually once a week if you’re lucky you’ll find some bickies in the kitchen, presumably left by the biscuit fairy.

Death March by Edward Yourdon

- published by Prentice Hall, 1997

When I first began reading this book, I thought it would be all about the team that came before us… the one that spent a lot of time delivering something that didn’t work. But the more I read, the more I found myself identifying our current team with the descriptions in each chapter. Curious as the title doesn’t sound that positive! As Wikipedia defines it, a death march project is one that is destined to fail.

One point that comes out repeatedly is that while in some ways “Death March” projects are not intended to be the norm, more often than not they end up being the de facto way that many IT projects are run.

In Ch. 1, characteristics of a “Death March” project are listed as including:

• Tight schedules
• Small team
• Limited budget
• More features
• Smaller scale

Hmm.. that sounds familiar!

In subsequent chapters he goes on to cover topics such as Politics, Negotiations, People, Processes, Tools & Technologies and finally the idea of “Death March” projects as a way of life.

In Ch. 3, the topic of Estimation is examined, and the value of having an experienced project manager who can estimate slightly better than just “gut feeling”, and that there are software estimation tools that can improve forecasting accuracy. I reckon Steve McConnell’s Software Estimation: Demystifying the Black Art (Best Practices (Microsoft)) could be worth a read to learn a bit more about this topic. I’ll add that to my wish list!

People can make all the difference, and our team certainly bears this out. I can’t agree with the comment that 80 hours a week is ok though.

Yourdon also espouses the importance of good workplace conditions – in particular quietness and privacy (eg. separate offices). There’s certainly empirical evidence to reinforce the productivity benefits, which flies in the face of the current trend of “open” office space, cramming as many people into tiny cubicles as possible.

Triaging tasks/bugs are critical, and allows you to prioritise what is important.

When this book was first published, there wasn’t much in the way of “Agile” development practises, but I think Yourdon is alluding to this when he makes mention of using RAD tools (refactoring), mini-milestones (iterations) and daily builds (continuous integration).

One thing I did find annoying was Yourdon’s use of a monospace font when listing the emails in each chapter’s list of references. This made them very hard to read and I mostly ended up skipping over them as a result.

Overall I came away inspired by this book. Yourdon highlighted the many pitfalls that await a team who are engaged in a “Death March” project, but does offer hope that under the right conditions, you can achieve success.