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

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
Wed Jan 10 12:46:45 CST 2007


"Dave Burns" <dburns0000@aol.com> wrote in message
news:%23HP81YNNHHA.4712@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
Fri Jan 12 09:41:36 CST 2007

Thanks,

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

dave

"Ben Voigt" <rbv@nospam.nospam> wrote in message
news:uPf9MeONHHA.4888@TK2MSFTNGP02.phx.gbl...
>
> "Dave Burns" <dburns0000@aol.com> wrote in message
> news:%23HP81YNNHHA.4712@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?
>>
>>
>
>