I actually finished reading this in March but have not gotten to writing about it until now. I'm falling a little behind and may have to skip my April reading and merge it into May. Ah well...to the story at hand.

This book was an excellent read and in an ideal format for me. The book is a collection of internally published essays within Microsoft that encompass a vast amount of topics regarding software development processes, management, coding, testing, career development, etc. The essays provided a great way for me to read bits and pieces in between work items and take the book in over the course of the month.

The essays were written by Eric and are not the standard "hooray for Microsoft and how we do things" line that you would expect. The essays tell it how it is and point out what Microsoft is doing / has done wrong and what they should be doing. In addition, the essays provide sane, to the point insights regarding industry tendencies, the good and the bad, and corrections that need to be made both from a practical and a theoretical point of view. They are by no means all encompassing, but do cover a good variety of areas.

I would definitely recommend this book to anyone who is planning on making a career out of software development. By career, I do not mean a tech-head who only cares about coding and nothing else. I also do not mean that you have to aspire for IT management. The book applies to anyone who is or wants to be involved with the software development life cycle as a whole.

Well, I finally finished Debugging Microsoft.NET 2.0 Applications by John Robbins. It took a while for a few reasons. First, I was reading a second book a long with this one that I’ll be finished with shortly. Second, work has been tremendously busy lately. Finally, the WinDbg section of this book is excellent, but can only truly be taken in when doing it in a hands-on manner.

This book is another one of those great desktop references for .NET, alongside of CLR via C#. At first thought, many would probably right off the book based on its title thinking that debugging in .NET is so easy that there is no need to read a book on it. However, this book provides an excellent footing on how to develop in a more debuggable manner, as well as, how to perform more advanced debugging; i.e., WinDbg. Of course, some of the book is the basic information that any seasoned developer is already going to know. Of particular interest to me were the sections on Symbol Servers and Source Servers (not SCMs) and their relation to doing hardcore debugging with WinDbg. Without a guide to get you started in WinDbg, I would think that it would take a very long time to come up to speed with its archaic IDE.

The only thing I did not like/agree with was the author’s obsession with Debug.Assert. Personally, I rarely use Debug.Assert. I prefer to catch my ‘assert’ scenarios and throw a proper exception. His lengthy argument and protesting did nothing to change my mind on the subject.

WinDbg is a great tool once you can get passed some of its archaic syntax. For advanced debugging, I know of no other way to dig deep and solve the problems. For hard core memory or threading issues, WinDbg is a must have. So, that being said, a colleague of mine gave me this listing of common WinDbg commands, which he grabbed from somewhere out there and added to. I then added more to it as I read Debuggin Microsoft.NET 2.0 Applications by John Robbins. So I am putting it out here for further reference.

Mark's WinDbg Common commands.doc (75.00 kb)

Get ready for the matrix that is the mother of all others. Here is a link to the Visual Studio 2008 Feature Comparison Chart or Visual Studio 2008 Edition Comparison Chart. It is enormous, but helpful, thus why I am linking to it.

I just installed Vista SP1 on my two work PCs. The install process took about an hour, but can be done unattended. It just reboots the machine about half of the way through. I must say with my first two tests, a file copy and a CD burn, it seems noticably faster. I hope that keeps up.

Is a pain in the ass. Yes, I said it, sorry. I know a there are a growing number of people out there using Firefox. Heck, I used to be one of them back when IE sucked, but it doesn't suck anymore. For those who are in Firefox, note that I finally got around to fixing a display issue with Firefox for this blog today. It had to do with a div that I had overflow set to visible on. It worked fine in IE, but in Firefox it caused the div not to stretch with its content. By switching the overflow to hidden, the content then displayed correctly, the div stretched in both IE and Firefox.

My question is, why? Why do different browsers interpret the same code in different ways, when there are, and have been, known standards out there for how to interpret the code? I am hoping IE 8 and its standards by default mode might help the symbiosis here, but come on, we are nearly 20 years into graphical browsers at this point. It shouldn't be this difficult to find these minute display issues.

 

Ok, I'm about a decade behind the times on this one, but for the longest time I've been reading my RSS feeds in Outlook. It isn't horrible, but the download approach is not really ideal for the feeds that I read, some of which have 200+ posts a day. I recently started using Google's reader and love it. They have a very slick AJAX scrolling region that loads on demand as you scroll the list. Live search had a similar idea when it first came out, but they backed off of it for some reason. It's really nice to be able to scroll through a long list and not have to worry about clicking next page. I really hope that feature catches on for other sites as well.

I just read about a useful .NET tool that I had not previously heard of. It is called the Fusion Log Viewer (or Asembly Binding Log Viewer). It ships with the Framework SDK as fuslogvw.exe and will display the assembly loading details for a .NET program. Between probing elements, GAC, satellite assemblies  and dependent assemblies, this tool could come in handy if you are having issues in this area.

Windows Error Reporting is a 'free' service from Microsoft that integrates into your product and allows end-users to report detailed error information to Microsoft. Microsoft then passes this information on to the vendor (you) in the form of mini-dumps and error reports that can then be debugged inside of Visual Studio and/or WinDbg. This seems like an invaluable service to an ISV that runs their products on Windows. For WinForm applications, there is a dialog that appears that allows the user to click 'Send Error Report'. I would hope there is also a way to automate the error reporting as there could be no user interface to the product (e.g., Windows Services).

The kicker to WER is that you need to have a digital certificate which is not cheap. However, depending upon the breadth of your customer base, it may be well worth it.

Microsoft has a shareware starter kit that appears to provide quite a few useful tools to help a new author get started and it is free of charge. Here is a run down of some of the features:

• Buy Now Web Service
• Activate Now Web Service
• Product Registration Web Service
• Product Feedback Web Service
• Exception Handling Web Service
• Multi-Threaded Splash Screen
• Configure Your Token
• Upgrade Version Web Service
• Log File Web Service
• Custom Developer Portal