"Hijacking .NET Vol 1: Role Based Security by Dan Appleman
Hijacking .NET is today's equivalent of using undocumented Windows API functions. Except that not only are the functions under discussion undocumented, they are actually private functions internal to the .NET framework that were never intended to be used from outside. In this Ebook, Dan will teach you how to find these hidden functions, how to use disassembly and common sense to figure out what they do, and how to implement code that uses"
[via .NetWire]
[Diclamair: The Next lines talk about the Dangers that lie in these kinds of books if used for production code. For any other purpose this is probably a 'run-to-get-it' kind of book. ]
Here we go again. Why on earth would anyone want to do this? This isn't VB6 we're talking about, where you miss some functionality and you can't get it in another way. Don't get me wrong, it's interesting. But this is just the kind of stuff people use for 'evil' and not for good.
Don't people get that if you use something the way it wasnt supposed to be used, you can get unexpected results, not to mention crashing and other stuff. this is just the kind of stuff VB6 developers were afarid of when trying to do multithreading using API calls. You just can't trust it enough to put it in production.
This book should come with a big red bold warning: "For Educational Purposes Only!".
Update:
Reading Over this post I feel complled to further state my views on this, as they seem unclear. I do NOT recommend that you do not buy this book. On the contrary, I think it is very important. However, the main problem with these kinds of books is that people tend to take them too far (mainly newbies) and make production code that takes extensive use of undocumented (and thus unsupported) functionality. Anyone who knows better would read this book carefully and 'use' it as a stepping stone to undestanding the source of problems and of solutions for those problems. This is just the sort of thing that begs the saying "With Power Comes Responsibilty". That's why my first reaction to seeing this book was "oh no, now again" .I've seen way too many VB6 programms that use Dan Appleman's VB6 API book and make it into the VB6 reference book instead of coming up with creative (and documented) ways of doing things.
I Can think of a very good example here from my VB6 days: VB6 has very poor string handling functions (performance wise) mainly ,string concatanation was a real bitch to deal with. This led to all sorts of classes being published on web sites that took extensive use of Win32 API's (i.e "CopyMemory" and sorts) that made string concatanation faster. Much Like today's StringBuilder Class.
Then I came accross a string concatanation class that does the same job, but outperforms all the other API based class modules. It used a simple "String(*)" buffer function (with some logic and some arrays) that is part of the VB6 language. Not a single API inside.
How's that for advocating use of documented only functionality?