The second edition of Programming .NET Components by Juval Löwy was a decent book on .NET techniques, though I found myself unconvinced by much of his advice. In particular, Juval is a big fan of interface-based programming, but doesn’t spend much time explaining the “benefits of interface-based programming” (p. 50). I find myself happy to have left it behind with COM. But perhaps some of this advice works better in “enterprise” situations than it does in client applications?

In any case, most of the value for me with books like this comes from learning things I didn’t know before, so here’s my list of the highlights (and criticisms):

• p. 30: He seems to claim that the “global namespace” is really just a top-level namespace named “global”, but I don’t find that to be the case.
• p. 55: He talks about “programming defensively” by checking to see if an interface is supported by an object. “Never assume an object supports an interface.” This advice may hold well with interface-based programming, but when you’re programming with concrete types, it’s better to throw an exception if you expect an interface that isn’t there.
• p. 56: He doesn’t articulate the “advantages” of using interfaces on structs very well. In particular, he doesn’t mention that casting a struct to an interface causes it to be boxed, in which case you may as well be using a class instead of a struct.
• p. 96: Here’s something I didn’t know: «using (null)» is legal; it simply does nothing at the end of the using block.
• p. 98: He has his own “dispose pattern,” but doesn’t seem to know that there’s a standard dispose pattern (or should explain why he doesn’t use it).
• p. 111: A SolutionInfo.cs file that is shared among all projects of a solution is a great idea that we’re using in our solutions at the office.
• p. 143: “You should always publish [events] inside a try/catch block” that eats the exceptions. I tend to put that responsibility on the client; ignoring exceptions is never healthy in the long run.
• p. 149: System.ComponentModel.EventHandlerList is a handy way to support large numbers of events without storing an individual delegate for each of them.
• p. 181: I didn’t realize that the AsyncWaitHandle of an IAsyncResult may not be released until the handle is garbage collected. I don’t agree with his advice to explicitly close the AsyncWaitHandle, though, because AsyncWaitHandle is often lazy-loaded; if the handle hasn’t been created, you’ll create it just to close it. Better to just leave it alone; some IAsyncResult implementations are smart enough to close the handle automatically when you call EndXxx.
• p. 198: He advises against setting IsBackground to true on a Thread; I agree. “You shouldn’t count on .NET to kill your background threads for you.”
• p. 204: I learned about “synchronization domains” (which are nothing like “synchronization contexts”) and “context-bound objects” – it reminds me a lot of COM apartments. Maybe someday I’ll find a use for them.
• p. 215: He unfortunately encourages the generally discouraged practice of locking “this” for synchronizing instance members and locking “typeof(ThisClass)” for static methods.
• p. 250: He jumps through a lot of hoops to make sure that raising an event can’t throw a null reference exception; I had never considered the problem of possible inlining. A good reason to avoid thread-safe events altogether, but I’d definitely use the do-nothing delegate trick before using a MethodImpl attribute to suppress inlining.
• p. 255: I forget that “managed threads” aren’t guaranteed to be actual individual physical threads.
• p. 263: Events can use ISynchronizeInvoke to raise events on the proper thread for a client with thread affinity.
• p. 268: I had forgotten about the XxxAsync/XxxCompleted/CancelAsync pattern provided by web service proxy classes.

I stopped reading carefully at this point – the rest of the material escaped my interest. To conclude this review, I’ll not discourage you from reading the book, but there are lots of other .NET books that you should read first.