How do I acquire MethodInfo WITHOUT hardcoding the method name in GetMethod!?

[AngryGerbil]

hey,
How do I acquire MethodInfo WITHOUT hardcoding method name as a
string?!??!The fact I have to use xxx.Gettype.GetMethod("MyMethod",
xxx) is making me want to drive an ice pick into my eye!
I have exhausted my resources and I cannot find a way out of it.
Having to use that creates a dangerous situation because the name of
the method could change. For instance, let's say you fav 3rd party
library rolls out a new version and the hardcoded strings won't match
it. Then you have to go through your code and hope to God you nail
them all or an exception will be thrown. Thats bad for huge production
code bases with hundreds of thousands of lines of code spread out all
over the place.

I need something, (anything!), like this:
==================
public sub MyMethod()
....do something
end sub

dim oInfo as methodInfo
oInfo = xxxxx.GetType.GetMethod(xxxxx.GetType.GetMethodNam e(MyMethod))
==================

Does somebody out there know something I don't? In Delphi....all I had
to do was "Somevar := @MyMethod" and I had what I needed. Of course, I
know thats bad bad in VB.NET, but some call that returns the string
name will work because I can then use the GetMethod without being
locked to a hardcoded method name. Any ideas? I'm desperate!

-The Angry Gerbil
(who wouldn't be angry if he could figure this out!)

[a]

Until someone smart shows up, have you looked through SYSTEM.REFLECTION?

Kevin

"AngryGerbil" <le******@comcast.net> wrote in message
news:aa**************************@posting.google.c om...

hey,
How do I acquire MethodInfo WITHOUT hardcoding method name as a
string?!??!The fact I have to use xxx.Gettype.GetMethod("MyMethod",
xxx) is making me want to drive an ice pick into my eye!
I have exhausted my resources and I cannot find a way out of it.
Having to use that creates a dangerous situation because the name of
the method could change. For instance, let's say you fav 3rd party
library rolls out a new version and the hardcoded strings won't match
it. Then you have to go through your code and hope to God you nail
them all or an exception will be thrown. Thats bad for huge production
code bases with hundreds of thousands of lines of code spread out all
over the place.

I need something, (anything!), like this:
==================
public sub MyMethod()
....do something
end sub

dim oInfo as methodInfo
oInfo = xxxxx.GetType.GetMethod(xxxxx.GetType.GetMethodNam e(MyMethod))
==================

Does somebody out there know something I don't? In Delphi....all I had
to do was "Somevar := @MyMethod" and I had what I needed. Of course, I
know thats bad bad in VB.NET, but some call that returns the string
name will work because I can then use the GetMethod without being
locked to a hardcoded method name. Any ideas? I'm desperate!

-The Angry Gerbil
(who wouldn't be angry if he could figure this out!)

[Rob Teixeira [MVP]]

You must use the name as a string. That's how the CLR and RTTI metadata
defines it. The name is never mangled or decorated as it is in pascal and C,
therefore the name in the code *is* the name reflection will use at runtime.
If the name changes, it is, by definition, not the same method.

-Rob Teixeira [MVP]

"AngryGerbil" <le******@comcast.net> wrote in message
news:aa**************************@posting.google.c om...

hey,
How do I acquire MethodInfo WITHOUT hardcoding method name as a
string?!??!The fact I have to use xxx.Gettype.GetMethod("MyMethod",
xxx) is making me want to drive an ice pick into my eye!
I have exhausted my resources and I cannot find a way out of it.
Having to use that creates a dangerous situation because the name of
the method could change. For instance, let's say you fav 3rd party
library rolls out a new version and the hardcoded strings won't match
it. Then you have to go through your code and hope to God you nail
them all or an exception will be thrown. Thats bad for huge production
code bases with hundreds of thousands of lines of code spread out all
over the place.

I need something, (anything!), like this:
==================
public sub MyMethod()
....do something
end sub

dim oInfo as methodInfo
oInfo = xxxxx.GetType.GetMethod(xxxxx.GetType.GetMethodNam e(MyMethod))
==================

Does somebody out there know something I don't? In Delphi....all I had
to do was "Somevar := @MyMethod" and I had what I needed. Of course, I
know thats bad bad in VB.NET, but some call that returns the string
name will work because I can then use the GetMethod without being
locked to a hardcoded method name. Any ideas? I'm desperate!

-The Angry Gerbil
(who wouldn't be angry if he could figure this out!)

[Armin Zingler]

"AngryGerbil" <le******@comcast.net> schrieb

hey,
How do I acquire MethodInfo WITHOUT hardcoding method name as a
string?!??!The fact I have to use
xxx.Gettype.GetMethod("MyMethod", xxx) is making me want to drive an
ice pick into my eye!
I have exhausted my resources and I cannot find a way out of it.
Having to use that creates a dangerous situation because the name
of the method could change. For instance, let's say you fav 3rd
party library rolls out a new version and the hardcoded strings won't
match it. Then you have to go through your code and hope to God you
nail them all or an exception will be thrown. Thats bad for huge
production code bases with hundreds of thousands of lines of code
spread out all over the place.

I need something, (anything!), like this:
==================
public sub MyMethod()
....do something
end sub

dim oInfo as methodInfo
oInfo =
xxxxx.GetType.GetMethod(xxxxx.GetType.GetMethodNam e(MyMethod))
==================

Does somebody out there know something I don't? In Delphi....all I
had to do was "Somevar := @MyMethod" and I had what I needed. Of
course, I know thats bad bad in VB.NET, but some call that returns
the string name will work because I can then use the GetMethod
without being locked to a hardcoded method name. Any ideas? I'm
desperate!

What other relation than the method name do you want? That's the only way to
identify a method. Maybe you're looking for a Delegate?

dim d as MethodInvoker
d = new Methodinvoker(addressof mymethod)

As you see, the method name is still hard-coded, so you would still have to
change it whenever the method name changes as you mentioned - so I do not
really understand the problem.

--
Armin

How to quote and why:
http://www.plig.net/nnq/nquote.html
http://www.netmeister.org/news/learn2quote.html

[Angry Gerbil]

Armin and Rob,
The reason I need this is very simple. I need it to validate at
compile time, not at runtime. A nightmare scenario is if I had a slew of
methods, and a slew of calls using GetMethod("xxxx") on those very
methods. Let's say some senior guy changes the names for some reason at
the core level. The lower level engineers aren't aware of the change.
The problem is the code still compiles. They have absolutely no way of
knowing it has failed until runtime (unless I am missing a trick). In my
experience, hardcoding the string of such things isn't necessarily a
good practice because it decouples it from the compiler. The compile is
our first line of defense as an engineer.
Anyway, this is the case with one of our products. I need to change
the way some large methods are called, but I cannot impact the flow of
the existing code, OR really change the flow of existing methods or
structures. This means no prototypes (delegates). I have devised a
successful, fast way to do this, but I need to be able to acquire
MethodInfo without hardcoding the method string in order to make it
-maintainable-!

-AngryGerbil

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[Rob Teixeira [MVP]]

I don't think the impact of my statement really sunk in :-)
The name of the method in source code *is* the method identifier (along with
its parameter signature) at runtime. If you change the name of the method in
code, the runtime will not be able to locate it afterwards. There is nothing
else to bind to. String name or nothing. And if you do change the name of a
function, the code that uses it will *not* compile. The low-level engineers
will indeed know something has changed because their code will break at
compile time (not runtime). This isn't like pascal or C where you can bind
to an arbitrary ordinal. The name is everything.

On the bright side, you don't need to validate anything. The compiler simply
won't find a method whose name was changed.
Of course... I seriously hope you are using early-binding. If not, this is
the least of your worries. With early binding, the compiler will catch
everything.

-Rob Teixeira [MVP]

"Angry Gerbil" <le******@comcast.net> wrote in message
news:Od**************@tk2msftngp13.phx.gbl...

Armin and Rob,
The reason I need this is very simple. I need it to validate at
compile time, not at runtime. A nightmare scenario is if I had a slew of
methods, and a slew of calls using GetMethod("xxxx") on those very
methods. Let's say some senior guy changes the names for some reason at
the core level. The lower level engineers aren't aware of the change.
The problem is the code still compiles. They have absolutely no way of
knowing it has failed until runtime (unless I am missing a trick). In my
experience, hardcoding the string of such things isn't necessarily a
good practice because it decouples it from the compiler. The compile is
our first line of defense as an engineer.
Anyway, this is the case with one of our products. I need to change
the way some large methods are called, but I cannot impact the flow of
the existing code, OR really change the flow of existing methods or
structures. This means no prototypes (delegates). I have devised a
successful, fast way to do this, but I need to be able to acquire
MethodInfo without hardcoding the method string in order to make it
-maintainable-!

-AngryGerbil

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[Angry Gerbil]

Rob,
Not sure if you got my last message. I completely agree with you, but
my point is that without a way to acquire the name of the method AS a
string, the method and the string constant are decoupled. There is no
way to make a large scale maintainable system where one must hardcode
the strings. That is why I need some way to acquire the string name of a
method. Then I can use the result of that and pass it into GetMethod.

Example in psuedo-code:

dim aMethodStr as string = GetType.ImaginaryMethodNameGetter(MyMethod)
Dim oMethodInfo as MethodInfo
oMethodInfo = GetType.GetMethod(aMethodStr)

This is something the compiler could even do if they gave us a
mechanism. Any more thoughts?

AngryGerbil

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[Armin Zingler]

"Angry Gerbil" <le******@comcast.net> schrieb

Armin and Rob,
The reason I need this is very simple. I need it to validate at
compile time, not at runtime. A nightmare scenario is if I had a slew
of methods, and a slew of calls using GetMethod("xxxx") on those
very methods. Let's say some senior guy changes the names for some
reason at the core level. The lower level engineers aren't aware of
the change. The problem is the code still compiles.
Set a reference and don't use reflection (explicitly) and the code won't
compile.
They have
absolutely no way of knowing it has failed until runtime (unless I am
missing a trick). In my experience, hardcoding the string of such
things isn't necessarily a good practice because it decouples it from
the compiler. The compile is our first line of defense as an
engineer.
Anyway, this is the case with one of our products. I need to
change
the way some large methods are called, but I cannot impact the flow
of the existing code, OR really change the flow of existing methods
or structures. This means no prototypes (delegates). I have devised
a successful, fast way to do this, but I need to be able to
acquire MethodInfo without hardcoding the method string in order to
make it -maintainable-!

If you change a name, you have to change the referring code. That's all I
can say.

You'd better think about not changing names! After a component is released,
public members shouldn't be changed anymore at all because it get
incompatible. Otherwise you're creating the problems on your own that you
are now trying to solve.
--
Armin

How to quote and why:
http://www.plig.net/nnq/nquote.html
http://www.netmeister.org/news/learn2quote.html

[Armin Zingler]

"Angry Gerbil" <le******@comcast.net> schrieb

Rob,
Not sure if you got my last message. I completely agree with you,
but
my point is that without a way to acquire the name of the method AS
a string, the method and the string constant are decoupled. There is
no way to make a large scale maintainable system where one must
hardcode the strings. That is why I need some way to acquire the
string name of a method. Then I can use the result of that and pass
it into GetMethod.

Example in psuedo-code:

dim aMethodStr as string =
GetType.ImaginaryMethodNameGetter(MyMethod)
Dim oMethodInfo as MethodInfo
oMethodInfo = GetType.GetMethod(aMethodStr)

This is something the compiler could even do if they gave us a
mechanism. Any more thoughts?

Where should "ImaginaryMethodNameGetter" get the name from? In this p-Code,
you are *passing* the name, so you are still hard-coding the name, and I
still don't see the point.
--
Armin

How to quote and why:
http://www.plig.net/nnq/nquote.html
http://www.netmeister.org/news/learn2quote.html