By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,617 Members | 1,166 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,617 IT Pros & Developers. It's quick & easy.

Calling a static method in another AppDomain

P: n/a
Hi

I have a scenario where I've created another AppDomain to dynamically load a DLL(s) into. In this newly loaded DLL I want to call a static method on a class. The problem arise is that I have the same class/static method definition statictly linked to my EXE and when I call InvokeMember(...), even though I got the Type from the new AppDomain, it calls the static method that I am staticly linked to and not the static method in the dynamicly loaded DLL

Does anybody know how to force a static variable call into another AppDomain if there is duplicate definition clashes across domains

I'll appreciate any help. Thank you
Chris
Jul 21 '05 #1
Share this Question
Share on Google+
5 Replies


P: n/a
Chris,

By domains do you mean namespaces? If you have two seperate namespaces, one
which is your library's, and the other is your programs, then reference your
built in static method like this

this.MyStaticMethod(...);

but then reference the one in the other namespace like this:

MyDynamicDomain.MyClass.MyStaticMethod(...);
If I've missed the boat, let me know.

Thanks.
Dan.
"Chris" <cp******@hotmail.com> wrote in message
news:FD**********************************@microsof t.com...
Hi,

I have a scenario where I've created another AppDomain to dynamically load a DLL(s) into. In this newly loaded DLL I want to call a static method on a
class. The problem arise is that I have the same class/static method
definition statictly linked to my EXE and when I call InvokeMember(...),
even though I got the Type from the new AppDomain, it calls the static
method that I am staticly linked to and not the static method in the
dynamicly loaded DLL.
Does anybody know how to force a static variable call into another AppDomain if there is duplicate definition clashes across domains?
I'll appreciate any help. Thank you.
Chris

Jul 21 '05 #2

P: n/a
I don't have the original post to reply to, but this is to address the
original post.

Have you tried using the Type.GetMethod() and then calling Invoke() on the
MethodInfo object instead? My guess is that theres some confusion, but at
least doing it this way, you can verify the MemberInfo (an ancestor of
MethodInfo) to be sure that it's on the correct type.

My guess is your Type.InvokeMember() is getting confused somewhere along the
way.

I had a similar problem a while back and by using the method I outlined, I
was able to track down the original problem with my Type.InvokeMember()
call.

Pete

"Daniel Bass" <DanielBass TAKE at OUT CAPS WORDS Postmaster.co.uk> wrote in
message news:%2*****************@TK2MSFTNGP10.phx.gbl...
Chris,

By domains do you mean namespaces? If you have two seperate namespaces, one which is your library's, and the other is your programs, then reference your built in static method like this

this.MyStaticMethod(...);

but then reference the one in the other namespace like this:

MyDynamicDomain.MyClass.MyStaticMethod(...);
If I've missed the boat, let me know.

Thanks.
Dan.
"Chris" <cp******@hotmail.com> wrote in message
news:FD**********************************@microsof t.com...
Hi,

I have a scenario where I've created another AppDomain to dynamically
load a DLL(s) into. In this newly loaded DLL I want to call a static method on a class. The problem arise is that I have the same class/static method
definition statictly linked to my EXE and when I call InvokeMember(...),
even though I got the Type from the new AppDomain, it calls the static
method that I am staticly linked to and not the static method in the
dynamicly loaded DLL.

Does anybody know how to force a static variable call into another

AppDomain if there is duplicate definition clashes across domains?

I'll appreciate any help. Thank you.
Chris


Jul 21 '05 #3

P: n/a
The problem is that even though you are creating a new appdomain you are
still calling it from the context of the default appdomain. You need to
create an object derived from MarshalByRefObj, create an instance of it in
the new appdomain and then via remoting into the new appdomain call a method
in it that will create the object and then call its method. This link does a
good job of describing things, and you can google up a bunch of sample code
pretty easily.

http://www.gotdotnet.com/team/clr/AppdomainFAQ.aspx
"Chris Mouton" <an*******@discussions.microsoft.com> wrote in message
news:5B**********************************@microsof t.com...

Hi Dan,

Thank you for replying. No when I mean domain, I mean AppDomain. Here is the sample code of the DLL that I am loading and the method that I'm
calling: AppDomainSetup setup = new AppDomainSetup();
setup.ApplicationBase = someDirectory;
AppDomain appDomain = AppDomain.CreateDomain("SampleDomain", null, setup);

Common.SampleInterface convertedClass = (Common.SampleInterface)
appDomain.CreateInstanceAndUnwrap(
"SampleDLL",
"SampleDLL.SampleDLLClass");

Assembly[] assemblies = appDomain.GetAssemblies();
Type type = assemblies[1].GetType("SampleNamespace.SampleClass", true, false); type.InvokeMember("Initialize"
,BindingFlags.Public | BindingFlags.InvokeMethod | BindingFlags.Static
,null
,null
,new Object[] {});

When this code is executed, the Initialize on my SampleClass from staticly linked DLL is called. I know this because I can have check code in the
SampleClass that says that it has not been initialized and if I look at the
Output window when in debugging mode, I can view that the wrong assemblies
are being loaded.
Does this help clarify the problem?

Kind Regards
Chris Mouton

----- Daniel Bass wrote: -----

Chris,

By domains do you mean namespaces? If you have two seperate namespaces, one which is your library's, and the other is your programs, then reference your built in static method like this

this.MyStaticMethod(...);

but then reference the one in the other namespace like this:

MyDynamicDomain.MyClass.MyStaticMethod(...);
If I've missed the boat, let me know.

Thanks.
Dan.
"Chris" <cp******@hotmail.com> wrote in message
news:FD**********************************@microsof t.com...
> Hi,
>> I have a scenario where I've created another AppDomain to
dynamically load
a DLL(s) into. In this newly loaded DLL I want to call a static method on a class. The problem arise is that I have the same class/static method
definition statictly linked to my EXE and when I call InvokeMember(...), even though I got the Type from the new AppDomain, it calls the static method that I am staticly linked to and not the static method in the
dynamicly loaded DLL. >> Does anybody know how to force a static variable call into another AppDomain if there is duplicate definition clashes across domains? >> I'll appreciate any help. Thank you.

> Chris


Jul 21 '05 #4

P: n/a

Hi David

Thank you for the link and although I've been through, I reread it to see if I missed anything the first time. What you describing is completely correct and it is exactly what I've done. Over the weekend I've written a small application and dlls to simulate the situation. I tried to incorporate all the suggestions that everybody has given me (thanks all!) but I can't seem to be able to call the static method in the other domain. First I thought it was a name clash, ie both AppDomain (current and loaded) has the same signature and the static method in the current AppDomain is callled only, but I found that I couldn't even call the static method in the loaded AppDomain under a new name

If anybody has any further suggestions on how to call a static method in another (dynamicly loaded) AppDomain, please let me know. Pretty please...

Thank yo
Chris Mouto

----- David Levine wrote: ----

The problem is that even though you are creating a new appdomain you ar
still calling it from the context of the default appdomain. You need t
create an object derived from MarshalByRefObj, create an instance of it i
the new appdomain and then via remoting into the new appdomain call a metho
in it that will create the object and then call its method. This link does
good job of describing things, and you can google up a bunch of sample cod
pretty easily

http://www.gotdotnet.com/team/clr/AppdomainFAQ.asp
"Chris Mouton" <an*******@discussions.microsoft.com> wrote in messag
news:5B**********************************@microsof t.com..
Hi Dan
Thank you for replying. No when I mean domain, I mean AppDomain. Here i the sample code of the DLL that I am loading and the method that I'
calling
AppDomainSetup setup = new AppDomainSetup()
setup.ApplicationBase = someDirectory
AppDomain appDomain = AppDomain.CreateDomain("SampleDomain", null, setup)
Common.SampleInterface convertedClass = (Common.SampleInterface appDomain.CreateInstanceAndUnwrap
"SampleDLL"
"SampleDLL.SampleDLLClass")
Assembly[] assemblies = appDomain.GetAssemblies()

Type type = assemblies[1].GetType("SampleNamespace.SampleClass", true

false) type.InvokeMember("Initialize
,BindingFlags.Public | BindingFlags.InvokeMethod | BindingFlags.Stati
,nul
,nul
,new Object[] {})
When this code is executed, the Initialize on my SampleClass from staticl linked DLL is called. I know this because I can have check code in th
SampleClass that says that it has not been initialized and if I look at th
Output window when in debugging mode, I can view that the wrong assemblie
are being loaded Does this help clarify the problem
Kind Regard Chris Mouto
----- Daniel Bass wrote: ----
Chris
By domains do you mean namespaces? If you have two seperat

namespaces, on which is your library's, and the other is your programs, the reference you built in static method like thi
this.MyStaticMethod(...)
but then reference the one in the other namespace like this
MyDynamicDomain.MyClass.MyStaticMethod(...)
If I've missed the boat, let me know Thanks

Dan "Chris" <cp******@hotmail.com> wrote in messag news:FD**********************************@microsof t.com..
Hi
I have a scenario where I've created another AppDomain t

dynamically loa a DLL(s) into. In this newly loaded DLL I want to call a stati method on class. The problem arise is that I have the same class/static metho
definition statictly linked to my EXE and when I cal InvokeMember(...) even though I got the Type from the new AppDomain, it calls th stati method that I am staticly linked to and not the static method in th
dynamicly loaded DLL. Does anybody know how to force a static variable call into another AppDomain if there is duplicate definition clashes across domains? I'll appreciate any help. Thank you.

Chris

Jul 21 '05 #5

P: n/a
I haven't tried calling a static method except indirectly when I used
ExecuteAssembly (this invokes the static Main method in the executed
assembly). Invoking an instance method was no problem at all. From your
sample code it appears that you are still not invoking the method in the
context of the remote appdomain. You should define a class, derived from
MBRO, that implements the functionality you are using directly from the
default appdomain. The code you show here...

Assembly[] assemblies = appDomain.GetAssemblies();
Type type = assemblies[1].GetType("SampleNamespace.SampleClass", true,
false);
type.InvokeMember("Initialize"
,BindingFlags.Public | BindingFlags.InvokeMethod | BindingFlags.Static
,null
,null
,new Object[] {});

....I assume you are executing from the default appdomain. By loading a type
into the default appdomain you are loading up all the assemblies as well
into the default appdomain, and it will try to execute the method in the
default appdomain. Create a method in convertedClass and move this code
into it so that when it call the method the code is executing remotely, and
call the method via the unwrapped object handle.

This wont necessarily solve the apparent problem of not calling the static
method. What error do you get? Are any exceptions thrown?

You can also try to use AppDomian.DoCallback(). This should invoke the
method in the context of the other appdomain. Again, I haven't used it with
static methods.

"Chris Mouton" <cp******@hotmail.com> wrote in message
news:3D**********************************@microsof t.com...

Hi David,

Thank you for the link and although I've been through, I reread it to see if I missed anything the first time. What you describing is completely
correct and it is exactly what I've done. Over the weekend I've written a
small application and dlls to simulate the situation. I tried to incorporate
all the suggestions that everybody has given me (thanks all!) but I can't
seem to be able to call the static method in the other domain. First I
thought it was a name clash, ie both AppDomain (current and loaded) has the
same signature and the static method in the current AppDomain is callled
only, but I found that I couldn't even call the static method in the loaded
AppDomain under a new name.
If anybody has any further suggestions on how to call a static method in another (dynamicly loaded) AppDomain, please let me know. Pretty please....
Thank you
Chris Mouton

----- David Levine wrote: -----

The problem is that even though you are creating a new appdomain you are still calling it from the context of the default appdomain. You need to create an object derived from MarshalByRefObj, create an instance of it in the new appdomain and then via remoting into the new appdomain call a method in it that will create the object and then call its method. This link does a good job of describing things, and you can google up a bunch of sample code pretty easily.

http://www.gotdotnet.com/team/clr/AppdomainFAQ.aspx
"Chris Mouton" <an*******@discussions.microsoft.com> wrote in message
news:5B**********************************@microsof t.com...
>> Hi Dan,
>> Thank you for replying. No when I mean domain, I mean AppDomain. Here is
the sample code of the DLL that I am loading and the method that I'm
calling:
> AppDomainSetup setup = new AppDomainSetup();
> setup.ApplicationBase = someDirectory;
> AppDomain appDomain = AppDomain.CreateDomain("SampleDomain", null, setup); >> Common.SampleInterface convertedClass = (Common.SampleInterface) > appDomain.CreateInstanceAndUnwrap(
> "SampleDLL",
> "SampleDLL.SampleDLLClass");
>> Assembly[] assemblies = appDomain.GetAssemblies();

> Type type = assemblies[1].GetType("SampleNamespace.SampleClass", true, false);
> type.InvokeMember("Initialize"
> ,BindingFlags.Public | BindingFlags.InvokeMethod |
BindingFlags.Static > ,null
> ,null
> ,new Object[] {});
>> When this code is executed, the Initialize on my SampleClass from staticly linked DLL is called. I know this because I can have check code in the SampleClass that says that it has not been initialized and if I look at the Output window when in debugging mode, I can view that the wrong assemblies are being loaded. >> Does this help clarify the problem?
>> Kind Regards > Chris Mouton
>> ----- Daniel Bass wrote: -----
>> Chris,
>> By domains do you mean namespaces? If you have two seperate namespaces, one
> which is your library's, and the other is your programs, then

reference your
> built in static method like this
>> this.MyStaticMethod(...);
>> but then reference the one in the other namespace like this:
>> MyDynamicDomain.MyClass.MyStaticMethod(...);
>>> If I've missed the boat, let me know.
>> Thanks.

> Dan.
>>> "Chris" <cp******@hotmail.com> wrote in message

> news:FD**********************************@microsof t.com...
>> Hi,
>>> I have a scenario where I've created another AppDomain to

dynamically load
> a DLL(s) into. In this newly loaded DLL I want to call a

static method on a
> class. The problem arise is that I have the same class/static
method > definition statictly linked to my EXE and when I call

InvokeMember(...),
> even though I got the Type from the new AppDomain, it calls the static
> method that I am staticly linked to and not the static method

in the > dynamicly loaded DLL.
>>> Does anybody know how to force a static variable call into
another > AppDomain if there is duplicate definition clashes across

domains? >>> I'll appreciate any help. Thank you.
>> Chris
>>>

Jul 21 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.