Why I Wrote This Book

When presented the opportunity to write this book, I thought long and hard before taking the offer. I tried to figure out how I might differentiate a project like this from other existing books on the topic. Not so long after, I realized something: I had not even read even one of the other .NET Framework books on the market. Yet I considered myself an expert.

The primary reason, I concluded, that I hadn't read any other was simply that I strongly disliked the level of content and writing style that most of them employed. Most authors chose to write about the Framework in a manner much like the Software Development Kit (SDK) documentation that comes with the product, assuming an overly elementary and introductory style. Clearly, reading product documentation helps one to understand the surface area, but I wanted more than that. The documentation is free, after all!

If I wrote this book, it had to be something that I would enjoy reading. The components I thought necessary to achieve this goal were:

• Not only the what, but the how and why behind the technologies. This means a deep discussion of the internal workings where it sheds unique insight on a topic or even disagreeing with a design decision if it's clearly a tad out-there. Reading a book that's purely about what a platform has to offer is ordinarily a dry experience, and can quickly reduce a book to reference-materialonly status;

• Tie-ins and cross-references with other technologies when explaining important concepts must be provided. The .NET Framework and CLR are not the first platforms on the block, so ignoring prior art seems like a crime to the reader. I've assumed that the reader of this book already understands how to program, so explaining how the technology being explained might compare to existing platforms that one might be familiar with can be helpful. Even if the reader isn't familiar with related technologies, it's often nice to know that this isn't the first time some (crazy) idea's been implemented;

• Complete as possible coverage, but without hiding incompleteness. Wherever a loose end must remain untied, pointers to relevant resources can be used to follow up and learn more on your own time. Obviously, no author can write about every component of the .NET Framework or CLR in any respectable level of detail within less than 10,000 pages. Rather than pretending that precisely this has been accomplished, leaving breadcrumbs for your readers' own research enables them to follow up at their own pace or when it becomes necessary.

With those guidelines in mind, I accepted the offer and undertook a year-long exploration. It was certainly a fun ride. In rereading what I've written over the past year, I feel that I've done reasonably well on all of the above accounts. I hope you agree.