If you're interested in the new rendering engine used by Longhorn, you should read Chris Anderson's latest article on Avalon, “The Blinking Lights Division”. It greatly assisted my understanding of the subject. It seems that the focus is always on XAML markup, and you probably know that it's possible to add shapes (elements, visuals) with plain old code, but did you know that Avalon also has an equivalent to the GDI device context called the DrawingContext, with methods like DrawRectangle()? Great stuff; it's all starting to make sense...

I've never been very comfortable with third-party components – mostly for the typical ego-driven reasons, e.g., they don't do things exactly how I would do them, etc. However, I've had enough trouble with third-party components that I feel some of my hesitance is justifiable. In fact, I'm ready to give up on “closed source” third-party components altogether, primarily because fixing critical bugs or adding missing features can be difficult (you have to convince the company that the change needs to be made, and then you have to wait for them to make the change, and test the change, and hope that they didn't break something else) or impossible (the company is no longer actively developing that product, or the company is no longer in business).

In the future, I'll be looking for component vendors that provide source code to their customers; Dan Appleman makes a good argument for this. Not only is this the “ultimate security blanket,” but seeing out how the component works is often quite useful when you're trying to use a component. Furthermore, when something breaks, and you're trying to figure out if it is your fault or that of the component, being able to debug their source code can be invaluable.

When an XmlDocument of the .NET Framework is used to load an XML file that references a DTD, that DTD (and supporting files) are parsed, even if they must be downloaded over the Internet! This, in my humble opinion, is an unexpected thing, and thus a bad thing. A coworker of mine wondered why simple manipulation of an XHTML document with the correct document type declaration was taking seconds instead of milliseconds – this was why. Every element insertion seemed to be delayed by a second or so!

The problem, as documented in this blog post, is that the default XmlResolver is an instance of XmlUrlResolver. If you want to ensure that your XML document manipulation is not hampered by the downloading and/or parsing of external entities such as DTD's, be sure to set the XmlResolver property of your XmlDocument instance to null before using it.

    XmlDocument doc = new XmlDocument ();
    doc.XmlResolver = null;

I can certainly envision a great book on design patterns that uses C#, but I'm afraid that C# Design Patterns: A Tutorial, by James W. Cooper, isn't it.

The first strike against the book is that it starts with a long, half-hearted introduction to C#. Certainly I'm reading this book because I already know C#, not because I need someone to teach it to me. If I didn't know C#, wouldn't I read a book with that target audience?

The second strike against the book is that the C# code all looks like Java code. Thus did I do a search on Amazon, fully expecting to find a book entitled Java Design Patterns: A Tutorial by the same author. I was not disappointed in my search, but I am disappointed that the author didn't bother porting the code examples more intelligently. I mean, the Observer pattern doesn't even mention events...

The third strike against the book is the overly complex examples. I'm all for examples that go beyond the classic Foo and Bar, but using Windows Forms, ADO.NET, etc., to demonstrate the standard design patterns is going too far, and distracts from the message.

Yer out! I do not recommend this book. Stick with the Gang of Four book, and check out this design pattern code library instead – it's got a simple definition, a UML diagram, a “structural” C# code sample, and a “real-world” C# code sample for each of the classic design patterns!

If you're eager to see how the use of generics is going to actually play out in the base class library of the .NET Framework – not to mention how you'll be using generics in your own libraries – the Design Guidelines for Generics are a must-read. I found them quite fascinating and altogether reasonable. Nice work!

Thanks to Ian Griffiths, I now love ClearType a little bit less. I won't be turning it off, of course, because it's better than the alternative, but give me IanType!

From the Namespace Naming Guidelines of the Design Guidelines for Class Library Developers:

Do not use the same name for a namespace and a class. For example, do not provide both a Debug namespace and a Debug class.

If you want to avoid bizarre C# compiler errors, you would do well to follow this rule. In fact, don't give classes the same name as any part of any nested namespace. For example, if there's a MyCompany.MyFeature.MyLibrary namespace, you should avoid defining a MyCompany, MyFeature, or MyLibrary class, in that namespace or any other.

It ultimately comes down to conflicts with the using-namespace statements that you'll probably try to use. I've played around with it a bit and have been unable to put my finger on the method to the madness. When writing libraries, it is often tempting to create a class with the same name as the last part of the namespace; don't do it.

I struggled for a while with a bizarre .NET assembly problem last night – I was getting a runtime exception when trying to access a new type in a strong-named library from a strong-named executable. Compilation was succeeding, and the assemblies were in the same directory, so I couldn't figure it out.

My first instinct was that the assembly must be in the global assembly cache (GAC), since I remembered that the GAC is checked even before assemblies in the same directory when everything is strong-named. But it wasn't there. So I finally ended up using the Assembly Binding Log Viewer (Fuslogvw.exe) for the first time. The executable wasn't having any trouble locating the library, so I had to set the ForceLog registry value to get more information. As it turns out, it was getting the assembly from the “download cache.” I didn't really know much about the download cache, presuming that it would never affect local assemblies, but somehow, though I haven't figured it out yet, I managed to get my assembly into the download cache, and the .NET Framework was using the old assembly without the new type from there.

Of course, I could have avoided this trouble altogether if I'd made sure that I was advancing the assembly version with every build. I've read arguments for and against the asterisk-syntax for assembly versions (e.g., “1.0.*”) – this seems like a pretty good argument for...

The intersection of the .NET Framework and XML is certainly worthy of its own book, and Applied XML Programming for Microsoft .NET, by Dino Esposito, fits the bill nicely. It was quite refreshing to read a specialized technical book that doesn't teach you the basics, but goes straight into the interesting topics. This book doesn't start by describing the CLR, or how to write C# code, or even what an XML document looks like. Instead it starts with the unique low-level XML parsing technology provided by the .NET Framework, explaining why the standard XML DOM isn't good enough (it requires the entire XML document to live in memory) and why the pull model of XmlReader is more useful than the push model of SAX (which can easily be implemented with XmlReader, but not vice versa).

The XML support of the .NET Framework uses many different technologies (DOM, DTD, XSD, XPath, XSLT, etc.), and I thought that Dino did a good job of representing those technologies without reproducing their specifications. I love XPath, so I took special interest in the XPathDocument class, an alternate representation of an XML document that's optimized for XPath queries. I also enjoyed the chapter on XML serialization, and now have a firm grasp of the difference between the SOAP formatter and the XML serializer, which both convert between objects and XML, but do so in very different ways. I'm not much of an ASP.NET/ADO.NET guy, so the stuff about data sets and Web services wasn't that useful to me, but it was easy to skip/skim.

Every .NET developer should read this book (because every .NET developer is going to have to work with XML sooner or later). I only hope that I can find more specialized technical books like this one that don't spend the first 100 pages telling me what I have already learned from the “broad overview” books.

Programming Microsoft .NET, by Jeff Prosise, is a well-written book about the .NET Framework. It focuses heavily on ASP.NET, which shouldn't be terribly surprising, considering that the .NET framework provides the most immediate productivity for Web development. The book gives only a chapter to client application development through Windows Forms, but it's a long chapter, and other books have been written to fill the gap. I especially enjoyed the chapter on ADO.NET, which gave a good introduction to accessing databases with .NET without going too far over my head.

This book is great for experienced Windows developers that want to understand the .NET Framework. There is very little coverage of Visual Studio .NET, which is a good thing, as it ensures that the reader understands the underlying concepts. Even with some .NET experience, I found that the book discussed topics that weren't covered in other similar books. For example, I wasn't familiar with the concept of background versus foreground threads in .NET until I read that section in the chapter on multithreading. (Background threads will not keep the application alive even if they are still running.) The book certainly can't cover the full breadth and depth of .NET, but it should enable the reader to become quickly productive with C# and .NET.