Monthly Archives: January 2007

Deep Computing Philosophy from Steve Yegge

If you haven’t read Steve Yegge, you owe it to yourself to do so. He only writes about once a month, but every single article is worth reading, whether you agree with him on everything or not. His latest is fascinating and incites some interesting pondering about the future of software…I’m going to have to think about a lot of it…


Check out my latest book, the essential, in-depth guide to performance for all .NET developers:

Writing High-Performance.NET Code, 2nd Edition by Ben Watson. Available for pre-order:

Importance of disposing MailMessage objects

Always, always, always follow the suggested usage patterns of disposable objects. I had a strange problem recently where e-mail messages with attachments weren’t releasing the lock on the files for a long time. I was using the System.Net.Mail namespace, specifically the Attachment and MailMessage classes.

Disposable objects represent resources not directly under control by the CLR–and this includes SMTP connections. By not calling dispose, the mail message was just sitting around, not getting sent. Why this is the case when I explicitly call SmtpClient.Send is unclear. The main symptom of this problem was that files that I attached to the e-mail message were still locked when I tried to delete them immediately after the send.

Something like this will do:

using (MailMessage msg = new MailMessage()) 
{ 
    msg.Attachments.Add(...); 
    client.Send(msg); 
}

Check out my latest book, the essential, in-depth guide to performance for all .NET developers:

Writing High-Performance.NET Code, 2nd Edition by Ben Watson. Available for pre-order:

Changes in .Net 1.1. and 2.0 E-Mail classes

I recently (re?)learned a harsh lesson at work. We migrated a critical application’s e-mail client code to use System.Net.Mail‘s classes instead of those in the deprecated System.Web.Mail.

After doing this, we immediately had three problems, mostly with the Attachment class:

  1. Our automated test software could no longer read the attachments
  2. Attachments started having names of Directory_Directory_FileName (they were just Filename)
  3. The software could no longer delete the attachment files from disk after they were e-mailed (the file was still in use).

With problem 1, it turned out that the default encoding in the old MailAttachment class was 7Bit and the test program (which I didn’t write) was directly scraping the mail queue (on a Linux system) and reading the encoded text, looking for recognizable tokens. The new class’s default encoding was Base64–gibberish, to this test┬áprogram. It wouldn’t really matter to our end-users, but the taking the “easy” way out in writing the test program locked us into an encoding. It just so happens, though, that 7Bit encoding is preferable in our circumstances, even for end-users (Base64 adds significant e-mail overhead–some of our users pay by kilobyte).

The 2nd problem took me a little longer to figure out. At first I thought it was a bug in the attachment naming code, but I couldn’t find anything either in code or the file system. It turns out that the name of the file that the Attachment class is giving includes the directory structure in the name–this seems quite odd–I mean, how often do you want a file name like that? So I manually set the ContentDisposition.FileName property to be just the filename.

I still haven’t completely figured out #3. I think it’s because the MailMessage class is locking the file during send, and not releasing it as early as the old class. In any case, I haven’t directly solved the problem, just come up with a semi-elegant workaround.

Lessons:

  1. Don’t assume default settings are the same across framework upgrades.
  2. Build unit tests to test the assumed stuff–even the stuff controlled by the framework. Don’t assume it’s doing exactly what you want with default settings.
  3. Most importabtly, if your functionality depends on specific settings, then explicitly specify them–don’t ever leave them to chance.

Thankfully, these were relatively easy to diagnose and caused minimal to moderate impact.


Check out my latest book, the essential, in-depth guide to performance for all .NET developers:

Writing High-Performance.NET Code, 2nd Edition by Ben Watson. Available for pre-order:

Fahrenheit 451

I just read the book Fahrenheit 451 by Ray Bradbury. This is the first time I’ve read it, never having come across it in school, like most people seem to. To me, it was the greatest argument against getting a TV. My wife and I decided towards the beginning of our marriage to never subscribe to cable TV. My parents never did while I was growing up. We will probably get a TV at some point, but it won’t be hooked up to anything but a DVD player.

The theme of the book was not exactly what I expected: I had always heard it was about government censorship, and it is–sort of. The more important theme running through it is the danger of intellectual laziness. It portrayed a world where various minority groups demand that offensive books be banned, eventually leading to the solution of burning nearly all non-trivial books (operating manuals and such).

The point is that the problem started with the people, not the government. They demanded softer forms of entertainment: TV in it current form, comics, music. And all of those media were dumbed down to the point of banality as well.

Those media don’t HAVE to be so mindless, but in their present form they largely are. Books that challenge or expand our thinking are crucial parts of our society and personal development. This is something I’ve been taught since a very young age–and it’s why I’ve got about 2,000 books in my home right now, waiting to be read or re-read, and why I can’t resist buying a new book almost every month!


Check out my latest book, the essential, in-depth guide to performance for all .NET developers:

Writing High-Performance.NET Code, 2nd Edition by Ben Watson. Available for pre-order: