I for the most part understand how pure assemblies work with app domains,
but I am not at all clear on what you can do with mixed-mode assemblies in a
multi-application domain situation. I'll elaborate a little on my
particular scenario in a moment, in case it's actually useful, but what I am
really in need of is a decent understanding of if/how one can leverage
mixed-mode assemblies from "non default" application domains. My great fear
is that the answer is "You cannot create/reference instances of types from
mixed-mode assemblies in non-default application domains and expect to do
anything useful with them". If that is true, the documentation would be
improved by spelling it out in both the AppDomain overviews and MC++
overviews.
If I have a mixed-mode type that uses IJW to leverage native code, can I
call/manipulate instances of such a type from an otherwise "clr pure"
assembly in a non-default application domain? If yes, then what about
inheritence? In other words can a type that is in a "non mixed-mode"
assembly, but which derives from a type in a mixed-mode assembly, function
properly in a non-default application domain? Yes or no?
The latter is my situation. From my mixed mode code in the default domain I
use AppDomain.CreateInstance() to instantiate an object in another domain of
a type that inherits from a mixed-mode type. The constructor for that
derived type does get run and I can trace through it to it's point of death.
The first thing it does is call the mixed-mode base type's constructor and
it goes into it just fine. That base-type constructor goes out to native
code with IJW just fine. It is when it trys to come back into managed code
with IJW in the mixed-mode base type constructor that it goes boom. It
appears to go wrong inside of the thunk right there. My suspicion is that
the native-to-managed thunk contains an assumption that it is running in the
default application domain and that the default application domain is not
actually "current"; that the runtime let me make a direct call from a type
that was loaded in another domain to the base type that was ONLY loaded in
the default domain. If that is the case it seems as though the runtime and
compiler/linker could conspire to flag this at runtime rather than letting
you hang yourself. In other words, if those are the rules, could not the
compiler discover that the class being compiled had references to mixed-mode
assemblies (even though it was otherwise pure) and mark it as such so that
the runtime could throw a nice informative exception if someone tried to
instance the class in a non-default domain?
Can a mixed-mode assembly ever be "loaded" into a non-default application
domain? If the answer is no, then does that imply that types that are to be
instantiated in a non-default domain cannot directly use types from
mixed-mode assemblies at all?
-Bern
"Gary Chang" <v-******@online.microsoft.com> wrote in message
news:Yb**************@cpmsftngxa07.phx.gbl...
Hi Bern,
From your description, I understand that you got a
System.NullReferenceException when the C# type(derived from a mixed-mode
class) is being instanced in a non-default AppDomain, please correct me if
I misunderstand your issue.
Based on my knowledge, the System.NullReferenceException will be thrown
while the code referenced to an invalid object, in your case, I think
perhaps it reference to a object which created in another AppDomain.
Something like the description from the Don Box's <<Essential.NET>>
Chapter 8:
"
..
An object resides in exactly one AppDomain, as do values. Moreover, object
references must refer to objects in the same AppDomain. ...
Like objects, types reside in exactly one AppDomain. If two AppDomains
need to use a type, one must initialize and allocate the type once per
AppDomain. Additionally, one must load and initialize the type's module
and assembly once for each AppDomain the type is used in. Because each
AppDomain in a process maintains a separate copy of the type, each
AppDomain has its own private copy of the type's static fields.
..
"
Thanks!
Best regards,
Gary Chang
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no
rights. --------------------
