InvokeMember limitations

  • Thread starter Thread starter AlexS
  • Start date Start date
A

AlexS

I've called one of methods on my class with Type.InvokeMember - see sample
code below.

When I moved this code (enclosing procedure) into separate library (separate
from type, where I call member), call stopped to work. In dbgclr nothing
happens at all, during run I get exception that Member not found. However it
is present in target assembly. Type is detected Ok too.

Is that some kind of limitation for this call?

Anybody?

Sample code:

BindingFlags bf=BindingFlags.InvokeMethod

| BindingFlags.DeclaredOnly

| BindingFlags.Public

| BindingFlags.Static;

tp.InvokeMember("Execute",

bf,

null,

null,

parms);



The only difference with working code is that before everything was done in
same assembly (exe). Now called type (class) is in separate assembly. So
basically call is from one dll to another one.

Any hints, what could the problem? Why now target member can't be found?



Thanks!
 
One more remark to this.

Specified form of call produces MissingMethodException, which doesn't say
anything about which member is missing.

When I use tp.Name+".Execute" for member name, I get also
MissingMethodException, however, with name of member, which is wrong,
because class name is used twice.

E.g. if my class with Execute is NewClass, I get
Method <assemblyname - namespace>.NewClass.NewClass.Execute not found.

When I use for member name just "Execute" I don't get this message in
exception text. At the same time .Net specifies assembly name quite right.

Looks like I do something wrong when trying to call static public method
from one dll in another. However, .Net docs do not say exactly what.

Same happens if I use longer form of call like
Type.InvokeMember Method (String, BindingFlags, Binder, Object, Object[],
ParameterModifier[], CultureInfo, String[])



Any hints what to look for?
 
What is even more strange is that

tp.GetMethod("Execute") gets me proper result. It finds method and gets
proper parameters and result info.

So, maybe something wrong is with BindingFlags or default binder I use?

Please, anybody!


AlexS said:
One more remark to this.

Specified form of call produces MissingMethodException, which doesn't say
anything about which member is missing.

When I use tp.Name+".Execute" for member name, I get also
MissingMethodException, however, with name of member, which is wrong,
because class name is used twice.

E.g. if my class with Execute is NewClass, I get
Method <assemblyname - namespace>.NewClass.NewClass.Execute not found.

When I use for member name just "Execute" I don't get this message in
exception text. At the same time .Net specifies assembly name quite right.

Looks like I do something wrong when trying to call static public method
from one dll in another. However, .Net docs do not say exactly what.

Same happens if I use longer form of call like
Type.InvokeMember Method (String, BindingFlags, Binder, Object, Object[],
ParameterModifier[], CultureInfo, String[])



Any hints what to look for?





AlexS said:
I've called one of methods on my class with Type.InvokeMember - see sample
code below.

When I moved this code (enclosing procedure) into separate library (separate
from type, where I call member), call stopped to work. In dbgclr nothing
happens at all, during run I get exception that Member not found.
Click to expand...
However
it
is present in target assembly. Type is detected Ok too.

Is that some kind of limitation for this call?

Anybody?

Sample code:

BindingFlags bf=BindingFlags.InvokeMethod

| BindingFlags.DeclaredOnly

| BindingFlags.Public

| BindingFlags.Static;

tp.InvokeMember("Execute",

bf,

null,

null,

parms);



The only difference with working code is that before everything was done in
same assembly (exe). Now called type (class) is in separate assembly. So
basically call is from one dll to another one.

Any hints, what could the problem? Why now target member can't be found?



Thanks!
Click to expand...
Click to expand...
 
What do you pass as params to Type.InvokeMember(...) ?

If Type.GetMethod(...) gives you proper result why not using
MethodInfo.Invoke(...) ?
 
What do you pass as params to Type.InvokeMember(...) ?

If Type.GetMethod(...) gives you proper result why not using
MethodInfo.Invoke(...) ?
 
Bogdan,
I've put sample code into original code. Here it is

BindingFlags bf=BindingFlags.InvokeMethod

| BindingFlags.DeclaredOnly

| BindingFlags.Public

| BindingFlags.Static;

tp.InvokeMember("Execute",

bf,

null,

null,

parms);

tp - Type instance, which I got - it's value (reference) is Ok - points
where it should.
GetMethod I used only to check if Execute is visible or not. It is visible
but not for InvokeMember. As soon as I got Type in tp, I can invoke methods.
Like I said in original post - it works when everything is inside same
assembly (exe in my case). When invoking code was moved into dll and invoked
one into another one - InvokeMember started to fail with search.

So, I had to change my algo to use direct cast to interface to be able to
invoke Execute. I don't see where I am wrong with InvokeMember variant till
now. Do you?

Sorry for rather late reply - was away in another town...

Rgds
Alex
 
is Execute() a public static method?


AlexS said:
Bogdan,
I've put sample code into original code. Here it is

BindingFlags bf=BindingFlags.InvokeMethod

| BindingFlags.DeclaredOnly

| BindingFlags.Public

| BindingFlags.Static;

tp.InvokeMember("Execute",

bf,

null,

null,

parms);

tp - Type instance, which I got - it's value (reference) is Ok - points
where it should.
GetMethod I used only to check if Execute is visible or not. It is visible
but not for InvokeMember. As soon as I got Type in tp, I can invoke methods.
Like I said in original post - it works when everything is inside same
assembly (exe in my case). When invoking code was moved into dll and invoked
one into another one - InvokeMember started to fail with search.

So, I had to change my algo to use direct cast to interface to be able to
invoke Execute. I don't see where I am wrong with InvokeMember variant till
now. Do you?

Sorry for rather late reply - was away in another town...

Rgds
Alex
Click to expand...
 
Back
Top