I tend to work in patterns, where I occasionally get caught up by a particular topic and buy every book that I can find on the topic so I can dig deep into that topic. SQLCLR was one of those topics earlier this year, and for all the work that I have done, I don't actually have any SQLCLR running on a production SQL Server in my environment. There are a number of reasons for this, primarily, that the databases where I might use it, don't belong to me, they are vendor databases and I can't go play around with them. One of the books that I bought to learn from for SQLCLR was
Pro SQL Server 2005 Assemblies (Pro) by Robin Dewson and Julian Skinner
This book overall is not bad, but there are some technical errors in some of the information that it provides. The brief stint on Memory Management is not technically accurate, and does not discuss the differences between 32bit and 64bit SQL Servers. This book really is programmer based and not management or DBA targeted, so this may not mean that much to most people.
This book does a good job of introducing the structure and concepts for how to build the various SQLCLR Object types. It also does a good job of providing some best practices for implementation that will make it easier for CLR code to be moved from the database tier in SQLCLR to a application tier, should scale out be required due to problems or growth. The tips provided by the author actually save time, and make code reuse much easier between the application and the database.
Based on the other books on SQLCLR that I have read, I would rate this one at the top of the list. It gives the information needed to design and code SQLCLR objects in SQL Server. Not all of the examples are actually good candidates for CLR use in my own opinion. Some of them can be done with TSQL in a manner that performs better than the CLR provided, but the difference in performance is fairly minimal. It could simply be that the authors needed an example that didn't require a bunch of supporting structure behind it to keep things simple.