Where is ICLRRuntimeHost::GetDefaultDomain?

Where is ICLRRuntimeHost::GetDefaultDomain?

• Ojemzy

  The summary of steps you provided is correct.
  
  You'll get one callback each time an AppDomain is created, with the AppDomainManager for the particular domain.  As soon as your code forces the creation of the default domain, the first code that's loaded in will be your AppDomainManager, which will then do the callback to your host before other code gets to run.
  
  -Shawn
  
  

• abdu

  This is the way we use it in v1.1 in any case. We created and managed AppDomains on .NET side and just gave back COM interface to unmanaged host. Maybe it would be nice to get a hold of unmanaged interface without creating AppDomainManager because I think it's most common scenario. The way we did it in v1.1 is ICorRuntimeHost/GetDefaultDomain/CreateDomain/CreateInstance/Unwrap/QueryInterface.
  Maybe AppDomainManager is better. I'll try using it. Thank you!
  

• fromie

  Basically if I summarize the steps:
  
  1. Implement AppDomainManager derived class.
  
  2. Override InitializationFlags and return AppDomainManagerInitializationOptions.RegisterWithHost
  
  3. Define COM interface and implement it in AppDomainManager derived class
  
  4. Register the AppDomainManager through ICLRControl::SetAppDomainManagerType
  
  5. QueryInterface for custom COM interface the instance returned in IHostControl::SetAppDomainManager for custom interface.

  I haven't tried it yet. But it seems to much for what could have been done much easier before and in predictable way. Now I have to deal with callback from CLR.
  
  My main question now is: Is this callback that gives me AppDomainManager instance synchronous with CLR Start()
  How do I know when I'll be handed the AppDomainManager instance I need it right after I start the CLR. Thanks a gain!

  
  

• ShadeZero

  In the post-Beta 2 builds you should also be able to CorBindToRuntimeEx multiple times to get both the V1 & V2 interfaces if you find this too cumbersome.
  
  The one "gotcha" here is that if you want to use the extended V2 managers (starting w/ a SetHostControl call on ICLRRuntimeHost) then you'll need to bind to the v2 APIs first and then to the v1 APIs after that.
  

• Tomislav Kralj

  Hi Leon,
  
     With v2.0 of the CLR, we've tried to move as much of the hosting process into managed code as possible.  In this case, one way to get the ability to manipulate AppDomains in your host would be to provide an AppDomainManager.  Once inside your AppDomainManager you could set the InitializationFlags property of your AppDomainManager instance to AppDomainManagerInitializationOptions.RegisterWithHost inside yoru InitializeNewDomain method.
     That has the effect of causing the CLR to call your host's IHostControl::SetAppDomainManager callback with a pointer to the AppDomainManager object itself.
     Since you can easily get a COM pointer to an AppDomainManager in this way, you could define an interface that it supports, and in your host QI for that interface to make calls back into it.  One of these methods can easily be "CreateNewDomain" or similar.
     If you think of the hosting process of consisting of two halves now, the traditional unmanaged half, and the new managed half which is rooted in the AppDomainManager object model, things become a little more clear.
  
  Hope that helped.
  -Shawn
  
  

• SteveRyder88

  Thanks!
  
  Binding to both interfaces is much more acceptable than using AppDomainManager for this.
  
• Where is ICLRRuntimeHost::GetDefaultDomain?