The major problems I've encountered with test automation are not technical but managerial: It's rare that those with the planning and decision-making authority have the neccessary understanding of what test automation is and how it fits into the development/testing cycle. It's not "sped-up manual testing" and it's not "record and playback", although it may contain elements of both and more. It's a development effort in its own right and needs to be managed as such.
I've used many of the major commerical automation tools and developed others in-house and none of them are the silver bullets their vendors (and in-house evangelists) claim they are. In the past, you would have been hard-pressed to make the case to management for writing your own in-house full featured GUI testing tool. It required a developer skill set that many in QA - even those on automation teams - don't always have in sufficient depth (not to mention the fact that, most who do have the skills choose to make more bucks over in development).
What the maturing of .NET and Microsoft's UI Automation Library have done, I believe, is put the writing on the wall for commercial UI test tools such as QTP and Functional Tester (WinRunner is on life-support, soon to be removed).
As more desktop applications themselves gravitate towards .NET and, increasingly, native 64-bit, commercial tools are struggling to keep pace.
This book demonstrates the advantages automation developers have in creating their own automation tools for .NET-based applications, thanks primarily to the close tie-in with the reflection namespace, UI automation libraries and COM interop serivces. The C# or VB.NET language skill set, while not trival, is not the same as writing C++ COM/ATL code, which would have been the only plausible option a decade ago to create an automation tool.
People coming from a script language coding background, preferably with some native Win32 programming in their past, should transition to .NET languages relatively smoothly. If they have a solid grasp of the differences between unit testing, integration and system testing, there's much in this book to apply both literally and to use as a conceptual base for creating an automation tool even more tailored to your specific application needs.
I don't usually comment on other reviews but I have to say the examples in the book worked just fine on my XP SP3 desktop environment, running the latest version of the .NET framework. Having been around software development and testing for 20+ years I'm sure that person's frustrating experience was genuine, but it's unfair to give all readers the impression the book contains bad code.
What the book does contain in abundance is painfully bad English. I don't say this with any disrespect towards the authors. I'm sure they are doing their best and, as someone who speaks only one language (and struggles often with it), I respect anyone who attempts to learn and use another, especially in a technical field.
My criticism is aimed at the Sybex editors, who really dropped the ball here by letting an important book out the door without adequate review.