|
dev
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Calling from default AppDomain (native code) into another AppDomain (managed code), hosted by ASP.NEWe 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? "Dave Burns" <dburns0***@aol.com> wrote in message Why not? There's gcroot and HandleRef and so forth to help with that.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, Show quote > 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? > > Thanks,
I tried gcroot as well, but same result - still can't call across AppDomains. dave Show quote "Ben Voigt" <rbv@nospam.nospam> wrote in message news:uPf9MeONHHA.4888@TK2MSFTNGP02.phx.gbl... > > "Dave Burns" <dburns0***@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? >> >> > >  |
|||||||||||||||||||||||
Other interesting topics