Calling from default AppDomain (native code) into another AppDomain (managed code), hosted by ASP.NET

[Dave Burns]

Hello,

We have a situation where a managed C++ assembly links with native C++ dll.
There is a callback mechanism which calls back into the managed code
asynchronously. Since native classes cannot hold onto a managed reference,
we need to have a managed static member which we access during the callback
and then get into the managed code.

This works great in a console or WinForm app. But in ASP.NET it doesn't. The
reason is that each web site is loaded into its own AppDomain.

After some debugging we found out that the managed static is set on
AppDomain 2, but the callback happens on AppDomain 1 (the default domain).
When the callback code tries to access the managed static - it is undefined.

We found a way to do a call into a different AppDomain, but only when you
already have a reference to that AppDomain and we don't - there doesn't seem
to be a way to enumerate AppDomains in a process.

Has anybody else run into this?

Is there a way to have ASP.NET (or the CLR) to not load the native code into
the neutral domain, instead load it into each AppDomain?

[Ben Voigt]

"Dave Burns" <db********@aol.comwrote in message
news:%2****************@TK2MSFTNGP04.phx.gbl...

Hello,

We have a situation where a managed C++ assembly links with native C++
dll.
There is a callback mechanism which calls back into the managed code
asynchronously. Since native classes cannot hold onto a managed reference,

Why not? There's gcroot and HandleRef and so forth to help with that.

we need to have a managed static member which we access during the
callback
and then get into the managed code.

This works great in a console or WinForm app. But in ASP.NET it doesn't.
The
reason is that each web site is loaded into its own AppDomain.

After some debugging we found out that the managed static is set on
AppDomain 2, but the callback happens on AppDomain 1 (the default domain).
When the callback code tries to access the managed static - it is
undefined.

We found a way to do a call into a different AppDomain, but only when you
already have a reference to that AppDomain and we don't - there doesn't
seem
to be a way to enumerate AppDomains in a process.

Has anybody else run into this?

Is there a way to have ASP.NET (or the CLR) to not load the native code
into
the neutral domain, instead load it into each AppDomain?

[Dave Burns]

Thanks,

I tried gcroot as well, but same result - still can't call across
AppDomains.

dave

"Ben Voigt" <rb*@nospam.nospamwrote in message
news:uP**************@TK2MSFTNGP02.phx.gbl...

>
"Dave Burns" <db********@aol.comwrote in message
news:%2****************@TK2MSFTNGP04.phx.gbl...

>Hello,

We have a situation where a managed C++ assembly links with native C++
dll.
There is a callback mechanism which calls back into the managed code
asynchronously. Since native classes cannot hold onto a managed
reference,

Why not? There's gcroot and HandleRef and so forth to help with that.

>we need to have a managed static member which we access during the
callback
and then get into the managed code.

This works great in a console or WinForm app. But in ASP.NET it doesn't.
The
reason is that each web site is loaded into its own AppDomain.

After some debugging we found out that the managed static is set on
AppDomain 2, but the callback happens on AppDomain 1 (the default
domain).
When the callback code tries to access the managed static - it is
undefined.

We found a way to do a call into a different AppDomain, but only when you
already have a reference to that AppDomain and we don't - there doesn't
seem
to be a way to enumerate AppDomains in a process.

Has anybody else run into this?

Is there a way to have ASP.NET (or the CLR) to not load the native code
into
the neutral domain, instead load it into each AppDomain?