More book updates for Customizing the CLR

stevenpr — Thu, 07 Dec 2006 22:24:00 GMT

I’ve recently been made aware of two more updates I need to provide for my book on Customizing the .Net Framework CLR. As always, I apologize for any inconvenience these discrepancies may have caused.

Chapter 2, Page 7. The table which lists the methods on ICLRRuntimeHost indicates that more information about ExecuteInDomain is available in Chapter 7. I had not intended to cover this method at all in the book, but the forward reference still exists. If you’d like information on ExecuteInDomain I’d be happy to provide you with a sample.

Chapter 5, Page 90. The SetAppDomainManagerType method on ICLRControl is used to inform the CLR of the assembly and type that implements your domain manager. The code sample on page 90 calls SetAppDomainManagerType after the CLR has been initialized by a call to ICLRRuntimeHost::Start:

int main(int argc, wchar_t* argv[])

{

// Initialize the CLR using CorBindToRuntimeEx. This gets us

// the ICLRRuntimeHost pointer we’ll need to call Start.

ICLRRuntimeHost *pCLR = NULL;

HRESULT hr = CorBindToRuntimeEx(

L"v2.0.31113",

L"wks",

STARTUP_CONCURRENT_GC,

CLSID_CLRRuntimeHost,

IID_ICLRRuntimeHost,

(PVOID*) &pCLR);

// Start the CLR

hr = pCLR->Start();

// Get a pointer to the ICLRControl interface

ICLRControl *pCLRControl = NULL;

hr = pCLR->GetCLRControl(&pCLRControl);

// Call SetAppDomainManagerType to associate our domain manager with

// the process

pCLRControl->SetAppDomainManagerType(

L”BoatRaceHostRuntime, Version=1.0.0.0, PublicKeyToken=5cf360b40180107c, culture=neutral”,

L"BoatRaceHostRuntime.BoatRaceDomainManager"

);

// rest of main() omitted…

}

This is incorrect. SetAppDomainManagerType must be called before ICLRRuntimeHost::Start. Here’ the corrected code sample:

int main(int argc, wchar_t* argv[])

{

// Initialize the CLR using CorBindToRuntimeEx. This gets us

// the ICLRRuntimeHost pointer we’ll need to call Start.

ICLRRuntimeHost *pCLR = NULL;

HRESULT hr = CorBindToRuntimeEx(

L"v2.0.31113",

L"wks",

STARTUP_CONCURRENT_GC,

CLSID_CLRRuntimeHost,

IID_ICLRRuntimeHost,

(PVOID*) &pCLR);

// Get a pointer to the ICLRControl interface

ICLRControl *pCLRControl = NULL;

hr = pCLR->GetCLRControl(&pCLRControl);

// Call SetAppDomainManagerType to associate our domain manager with

// the process

pCLRControl->SetAppDomainManagerType(

L”BoatRaceHostRuntime, Version=1.0.0.0, PublicKeyToken=5cf360b40180107c, culture=neutral”,

L"BoatRaceHostRuntime.BoatRaceDomainManager"

);

// Start the CLR

hr = pCLR->Start();

// rest of main() omitted…

}

Thanks,

Steven

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

Book updates for Customizing the CLR

stevenpr — Wed, 29 Mar 2006 04:53:00 GMT

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.

Steven Pratschner's .Net CF WebLog : Custominzing the CLR book

More book updates for Customizing the CLR

Book updates for Customizing the CLR