I think the first thing to clarify is what this book is not. It is not a book for programming virgins, nor is it a book for those that do not already have at least an implicit understanding of object orientation. It is also not a book about programming for .NET nor is it a book about the way that C# has been designed. I think that last point is particularly important because many readers have an expectation that books with this kind of title will address the programming model that a language uses.
So what is this book? Well it is a fairly well written introduction to the C# language for those who are already reasonably competent with at least one other object oriented language. Those that already code in Java or C++ will find the material reasonably presented though a few more comments on the ways that C# differs from these popular languages would be helpful.
However where I completely part company with the author is in his example source code. Let me take just a single example. On pages 320-326 he purports to demonstrate how essential
gotois to writing source code. Now I will pass over his use of switch statements where any well trained user of an object-oriented language would wonder why runtime polymorphism has not been used because maybe he feels his reader will not be happy with having to deal with the subtleties of 'virtual construction' and simply say that in each of his examples I can think of a clean and simple way of writing the code without using
goto. Please note that I am not rabidly anti use of
goto, what does concern me is that so many programmers use it because they do not understand how to write code where its use is unnecessary.
Now, if you are happy to ignore the quirkiness of the author's code and be happy with learning the C# language in isolation then this book is acceptable. However please do not let weak programmers near it because it will only serve to re-enforce their bad habits. Also avoid letting novices anywhere near it.
Learning the syntax and basic semantics of a language is fairly easy; learning how to use a language to express thoughts and solutions clearly and correctly is more demanding. It takes time for languages to develop their own idioms that encapsulate good practice. It would be unreasonable to expect authors to understand or invent good idioms straight away. However they should not be repeating poor coding styles from other languages.