As a developer, IMHO you can't receive a bigger 'thank you' from your customers besides they being very happy than when they write a great review about your work or do the ultimate: write a whole book! 
. Joseph Chancellor wrote a book about Visual Studio.NET 2005, SQL Server 2005 and LLBLGen Pro called Rapid C# Windows Development. It walks the reader through a complete windows forms application for .NET 2.0 using the AdventureWorks database for SqlServer 2005 and LLBLGen Pro, from scratch to deployment and beyond.
I can only say: very very well done, Joseph! . The book is easy to read, addresses the complex issues one might encounter during development of an application very well and gives the reader not only insight how to handle the various stages of a typical windows forms application but also gives great tips along the way.
What I really liked about the book was that Joseph is able to explain complex issues in a very easy to understand way, with metaphores every developer understands. In other words: the book really explains things so the reader understands what's taught and is wiser after reading it. A key element for a book meant to be used for learning and Joseph succeeds magnifically in this.
I hope Joseph gets the chance with a high-profile publisher to write more books about software development, as his talent to explain things in a very understandable way is what's needed for modern books about software development, tools and techniques.
Rapid C# Windows Development: Highly recommended for every LLBLGen Pro user.
You know what's the most frustrating thing on earth? Writing code for design time databinding. If you've never tried it, and want to feel how frustration can flow throw a human body, please give it a try. If you're lucky you'll do everything right the first time, but as the documentation lacks and the code to write isn't that simple, you probably will make a few mistakes here and there. But that's not that bad, right? You have exceptions with stacktraces and debuggers, right?
Well... no. You could setup VS.NET to debug you design-time code, however that's a cumbersome experience at best. Best of all: if in your debugging session an exception is thrown somewhere in your own code, the debugger won't stop there, as it does with every other managed application run in the debugger. No, instead the exception will bubble up to VS.NET and two things can happen there:
- The IDE crashes. (Happens to me on VS.NET 2005 on a regular basis)
- You'll get a message like "Object reference not set to an instance of an object" or "Specified argument was out of the range of valid values. Parameter name: Index was out of range. Must be non-negative and less than the size of the collection" or similar. No stacktrace. That's right, no stacktrace.
Now, if your code is small, you could possibly place a breakpoint in every routine you have, but if your code is rather large, like 100,000+ lines of code and a lot of classes are involved, you're in serious trouble. Where did that lovely exception originate? If you would have a stacktrace, it would have been simple: check the stacktrace, place a breakpoint there and see what happens. After all, that's normal debugging procedure.
Not with design time databinding code and VS.NET. Stacktraces are considered a thing only stupids would use apparently and therefore not provided. I can tell you from experience, if you have to fix a problem which pops up an error originating somewhere in a .NET class but you have absolutely no clue where it originates from, it is frustrating, and then I'm putting it lightly.
Who decided to strip off a stacktrace in an exception! The same stupidity is present on the compact framework for .NET 1.x: "So, hotshot-developer, you want to bind a collection of objects to that grid in your mobile application, huh? Well, an error occured somewhere in the code you wrote and referenced. Where, I won't tell you. I know where it originates, but let's play a little game: you look for the root-cause and I keep my mouth shut, like it? No? Well, I don't care, deal with it. Back to stone-age gdb debugging style, baby!".
If you've never dealt with this kind of code, consider yourself lucky, and consider yourself warned: if your manager walks into the room and asks you if it's possible to write some design time databinding supporting code for a set of controls you wrote, remember what you just read.
Happy coding, although this kind of crap sucks all the motivation out of me to say "Yes, VS.NET is a great IDE". 
Today I was writing some additional mail functionality for our forum software we use internally. This is a .NET 1.1 application written with ASP.NET. I stumbled upon MailMessage.Fields and wondered what it was for so as a Good ProgrammerTM I pressed F1.
This is the full help, from the MSDN documentation library of October 2005 (so it should have that text by now, it's documentation for .NET 1.x)
MailMessage.Fields Property [C#]
Note: This namespace, class, or member is supported only in version 1.1 of the .NET Framework.
[To be supplied.]
[C#]
public IDictionary Fields {get;}
Requirements
Platforms: Windows 2000, Windows XP Professional, Windows Server 2003 family
See Also
...
Happy 2006! :) I hope for everyone 2006 will be a great, healthy, wonderful year! 