Releasing a book before the product on which it is based ships is always a risky proposition as product changes are inevitable, which may invalidate some of what you've written.  My situation is no exception.  I finished writing my book on advanced CLR programming techniques almost a year before version 2.0 of the .Net Framework was released.  Over time, various readers have pointed out places where the book is now inaccurate.  This post summarizes what's different and provides updated versions of all the book's samples.

• Chapter 7, Page 187. System.Configuration should be in the list of assemblies the CLR unifies when an application is run.
• Chapter 8, 196.  The GetTextualIdentityFromFile and GetTextualIdentityFromStream methods on ICLRAssemblyIdentityManager are now called GetBindingIdentityFromFile and GetBindingIdentityFromStream.
• Chapter 8, 209.  I suggest that the managed portion of the Cocoon host (the CocoonHostRuntime assembly) could be included in the cocoon along with the files that constitute the application.   While this is true, it's probably more of a hassle than it's worth because of security and evidence.  As described in Chapter 10, assemblies loaded from the cocoon are granted no evidence by default.  In order for them to run, the sample includes an implementation of HostSecurityManager that assigns a custom piece of evidence which causes the Application Domain's security policy to grant at least enough permissions to allow the assemblies in the cocoon to execute.  The problem is the implementation of HostSecurityManager that assigns the evidence and evaluates policy is contained in CocoonHostRuntime.  As a result, when CocoonHostRuntime is contained in the cocoon, it doesn't get permission to load.  Your classic "chicken and egg" problem....  You can work around this by modifying the machine's security policy to grant appropriate permissions to CocoonHostRuntime, but this complicates the deployment of your host.
• Chapter 14.  This chapter describes a set of hosting APIs you can use to integrate the CLR with an existing cooperative scheduling mechanism.  SQLServer 2005 is described as a host that has done this type of integration.  However, the SQLServer and CLR teams cut the ability to schedule the CLR onto SQL's fibers.  The hosting APIs described in the chapter still exist, but SQLServer doesn't use them.

In addition to these content changes, the book's samples could also use an update.  The updates can be found here.  Most of the samples are just rebuilt with the released version of Visual Studio 2005, which was generally straightforward. 

However, one sample, the AppDomainViewer sample from Chapter 5, has some worthwhile code changes.  There was a bug in the sample that caused the UI to not always be updated properly (I missed a case of Control.Invoke!).  Also, there are some cases where the profiling APIs which are used to attach to processes sometimes fail to attach.  Thanks to Paul Perry, most of those cases have been identified and some better error handling code now catches these.

Thanks,

Steven

This posting is provided "AS IS" with no warranties, and confers no rights.