Hi Todor,

As for custom CLR hosting scenario, if you want to communicate between your
unmanaged hosting application and the managed CLR runtime, you should make
use of the "AppDomainManager" (application domain manager). In .NET 2.0,
each appdomain can have an AppDomainManager and we can get the reference to
the AppDomainManager after it is created(or at initialize time). And for
custom CLR hosting scenario, you can use some certain interface method to
query the AppDomainManager interface pointer of the default AppDomain of
your managed CLR runtime.

#AppDomainManager Class
http://msdn2.microsoft.com/en-us/library/system.appdomainmanager(VS.80).aspx
#Mtps_DropDownFilterText

for detailed description on this, you can refer to the "Application Domain
Managers" section in the <Customizing the Microsoft .NET Framework Common
language Runtime> book (by Steven Pratschner). It is in the Chapter 5(using
application domain effectively).

Hope this helps.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


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

Hello Todor!

[quoted text, click to view]

You too? ;-)

[quoted text, click to view]

Starting from the ICorRuntimeHost interface, you have to get the _AppDomain
instance. The Domain may be the DefaultDomain
(ICodeRuntimeHost.GetDefaultDomain), or you may start a new AppDomain
(CreateDomain(Ex), ...)

[_AppDomain]
http://msdn2.microsoft.com/en-us/library/system._appdomain.aspx

When you have the _AppDomain instance, you can use all Methods like
"CreateInstance", or "CreateInstanceFrom" to create Objects.

[_AppDomain.CreateInstance]
http://msdn2.microsoft.com/en-us/library/system._appdomain.createinstance.aspx


[_AppDomain.CreateInstanceFrom]
http://msdn2.microsoft.com/en-us/library/system._appdomain.createinstancefrom.aspx

[quoted text, click to view]

Maybe there are other methods, but I am only aware of one way to do this:
You should make the Objects that you have to call from the unmanaged world
COM-Visible. Then you can call methods using COM (as done within the CLR
itself). I do not know how the SQL-Server integration has been managed.

[quoted text, click to view]

If I understand you correclty, you meen how the unmanaged Code gets
Methodcalls, Data, ... from the managed Code? Well, it's just a matter of
the Object-Model. If you have the ability to create objects, and call
methods (with parameters) from this object, you have everything you need.

If the managed Code should invoke unmanaged methods, you sould implement an
COM-based "Context" Object which is passed to the managed Object as an
Parameter. When the managed Code calls Methods from the Context-Object, it
calls the unmanaged Code via COM Interop.

With a proper Object-Model on the managed side, you can hide awai all this
unamanged / COM Stuff from the implementor of the managed Components (if
this is part of a bigger project).

[quoted text, click to view]

What kind of callback to you meen?



:: GP

I read the book "Customizing the MS .NET Framework CLR" By Steven
Pratschner. It describes how to host the CLR in an application for example
the way SQL Server hosts the CLR. It also describes in great details how to
control the CLR, the way it behaves.

What I am missing is, how does the host interact with the managed code in
the hosted CLR? How does the host create instances and invoke methods on
those instances? How does the host gets reply from the CLR? And how does the
CLR communicates to the host, if a callback is needed?

Thanks!

PS: I am not sure if this is the right group.

Se inline.

[quoted text, click to view]
It would be nice to head how MSSQL have implemented this.

COM is apparently the way to communicate to the CLR and to the host when it
comes to objects. I have to questions here:

1. If a have a class X with method Y, do I have to register the class as COM
server (gacutil.exe on the assembly, regasm.exe to make a typelib and
register it in the registry) or can I access the class in-place, meaning
that the COM interfaces are private to the class and the host only and the
rest of the world has no knowledge of those. The idea is to keep the host
machine clean and simplify deployment.

2. If I want to use an existing .Net class (from the host), let's say
System.Text.StringBuilder, how would that class have to be registered with
COM?


[quoted text, click to view]

I ment the return value.

[quoted text, click to view]

Yes, so the way to go is let the host implement a COM server and have the
CLR call the COM menthods in the host. Correct?

Hi Todor,

For custom CLR host scenario, the main approach to communicate between
unmanaged world to the hosting CLR is using the AppDomainManager, you get
the default domain's AppDomainmanager reference through certain interface,
and then query some custom interfaces(you've defined in your custom
AppDomainManager class). So what you need to do here is:

** define your own AppDomainManager class(managed class)

** in the AppDomainManager class, define some methods that can be correctly
called from unmanaged code through COM interop interfaces

At runtime, CLR will load your AppDomainManager class(you do not need to
explicitly host it as a COM server). And at unmanaged part, you need to get
reference to the AppDomainManager and query the certain interface(you've
defined in your AppDomainManger class).

As I mentioned in the previous message, you can refer to the "Application
Domain Managers" section in the <Customizing the Microsoft .NET Framework
Common language Runtime> book (by Steven Pratschner). It is in the Chapter
5(using application domain effectively).

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


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

Hi Todor,

Have you got any further progress or does the infornmation mentioned in
previous message also helps a little? If there is anything else we can
help, please feel free to post here.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


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

Hi Steven,

no further questions for the moment. I'll have to spend some time playing
with the technology.

Take care!

-- Todor

[quoted text, click to view]