Using ​System.​Reflection to obtain parameter values dynamically

I'm trying to come up with some code that I can use to add INFO level tracing to my DAL and BL code.  So far, I'm able to obtain plenty of metadata about the functions, but not the actual parameter values:

StringBuilder sb = new StringBuilder();

sb.Append(System.Reflection.MethodBase.GetCurrentMethod());

ParameterInfo [] ParameterInfos = System.Reflection.MethodBase.GetCurrentMethod().GetParameters();

foreach (ParameterInfo ParameterInfo in ParameterInfos)

sb.Append(" ").Append(ParameterInfo.Name).Append(" {").Append(ParameterInfo).Append("}");

TraceLog.Info(sb.ToString());



this will output the metadata about the parameters, but not the actual values.  For example, it will show me that the value is an Int32, but not that the value is 3.

I know that this is doable, but I can't seem to pick the right combination of words, punctuation, and secret masonic dances required to get Google to return a clue.

Any clues?

Edit: oh, and what the heck is the 'code' tag on C9 again?

OK, I'm going to have to believe you, because it just doesn't seem possible.

So, my next question is, how do I get a list of parameters and their values that were passed into my method?

Is this even possible? 

StackTrace
StackFrame

Try inspecting the call stack with System.Diagnostics classes?  Though I can't find the methods to crack the parameters.  If you find the answer to your question, please post it here!

JChung2006 wrote:

StackTrace
StackFrame

Try inspecting the call stack with System.Diagnostics classes?  Though I can't find the methods to crack the parameters.  If you find the answer to your question, please post it here!

Yeah, I looked at that, but it still won't give access to the values.

I might try to do this by emitting IL code with the name of the parameter followed by 'ToString()', but that seems to be way complicated.

Ion Todirel wrote:

yeah .NET API doesn't contains anything wich would help you to do that, there is Debugging API, maybe it can help you? i'll give it a try

I'll take a look at that tomorrow, too.  It seems that if the serializer classes can do this with an object, that it should be doable for method parameters.

It sure would make tracing a bit easier.

Thanks, all, for the input.

Ion Todirel wrote:

yeah .NET API doesn't contains anything wich would help you to do that, there is Debugging API, maybe it can help you? i'll give it a try

How does something like RhinoMocks manage to record the parameters passed into a method call?

EDIT: You could do sort of do this with DynamicProxies

This is proving to be much more difficult that I thought.

The weird thing, is that I can gain access to a ParameterInfo which contains the attribute 'name' as well as it's type.  I just can't figure out how to make .NET evaluate it

The System.Diagnostics.Debug sections didn't seem to hold any answers, either.

As far as I know there is no way to do this without using debugger APIs or something. We've had a thread about this in the Techoff before, it went nowhere then too.

littleguru wrote:



ScanIAm wrote: This is proving to be much more difficult that I thought. The weird thing, is that I can gain access to a ParameterInfo which contains the attribute 'name' as well as it's type.  I just can't figure out how to make .NET evaluate it

The ParameterInfo class comes directly from the metadata. It is part of the metadata that has been embedded for that class... You can get the properties also because the metadata is used to gain access to the class that you want to get the data from. The problem with parameters is that they don't exist in the class - they exist only on the stack for a given time... It's a completely different situation and has nothing to do with reflection - as it is implemented right now.

It's just so frustrating   I can almost 'see' the solution, but I get stymied at every avenue.

I went through some of the Type.Invoke code to see if that would work, but again, you need to somehow get access to the actual objects themselves.

The would surely be a nice 'feature' to add to the next version of .Net.

littleguru wrote:



ScanIAm wrote:  littleguru wrote:  ScanIAm wrote: This is proving to be much more difficult that I thought. The weird thing, is that I can gain access to a ParameterInfo which contains the attribute 'name' as well as it's type.  I just can't figure out how to make .NET evaluate it The ParameterInfo class comes directly from the metadata. It is part of the metadata that has been embedded for that class... You can get the properties also because the metadata is used to gain access to the class that you want to get the data from. The problem with parameters is that they don't exist in the class - they exist only on the stack for a given time... It's a completely different situation and has nothing to do with reflection - as it is implemented right now. It's just so frustrating   I can almost 'see' the solution, but I get stymied at every avenue. I went through some of the Type.Invoke code to see if that would work, but again, you need to somehow get access to the actual objects themselves. The would surely be a nice 'feature' to add to the next version of .Net.

It's how the system is build. if you look at it it is a stack machine. It is way complexer to fetch the data because it is not in a type or so... it's in the code... it's no member data at all. It's put dynamically on the stack and then the method is called.

It can't be that complex if the debugger is able to do it.  And, unless I'm confused, the ASP 'bind/eval' functions seem to be able to evaluate the data. 

I'm expecting to be able to trace this information at runtime, so why shouldn't I be able to 'see' inside the parameters at runtime?

I am not an expert. But it seems to me that your having some kind of mental block on this. That is, you appear to confusing your "cake recipe" with an actual cake.

As has already been mentioned, by the time your within an exception block, about the only thing left for you to do is to try and scrounge up whats left by trolling though the stack. ie the Debugging APIs.

About the only other way that I can think of is if you force all of your routines to use globals variables rather than parameters. As has already been mentioned, these parameters live on the stack, not on the heap (globals). And debuggers use the debugging APIs.

As for the ASP bind/eval stuf, I doubt your perception. Remember, your looking for the actual passed in parameters - the cake.

RichardRudek wrote:

I am not an expert. But it seems to me that your having some kind of mental block on this. That is, you appear to confusing your "cake recipe" with an actual cake.

The cake is a lie.

RichardRudek wrote:

As has already been mentioned, by the time your within an exception block, about the only thing left for you to do is to try and scrounge up whats left by trolling though the stack. ie the Debugging APIs.

This wouldn't be in an exception condition, but yep, someone did mention using the Debugging APIs.  I just haven't had a chance to look at them yet. 

RichardRudek wrote:

About the only other way that I can think of is if you force all of your routines to use globals variables rather than parameters. As has already been mentioned, these parameters live on the stack, not on the heap (globals). And debuggers use the debugging APIs.

But, .NET operates differently than an unmanaged app.  There aren't any INT13 calls to be made, because the CLR is processing and interpreting the IL.  It can stop any time it wants to whereas an unmanaged app needs to force the CPU to be interrupted.

RichardRudek wrote:

As for the ASP bind/eval stuf, I doubt your perception. Remember, your looking for the actual passed in parameters - the cake.

Yes, exactly.  For example, if I'm displaying a gridview, and using an ObjectDataSource, the only thing I need to tell the GridView is the 'name' of the return object.  It is able to take that 'name' and the Type and end up with the value found inside that variable.

In this case, I have the name and type of the parameters, but no way to get .NET to evaluate the parameter (like the GridView does). 

There has to be some behind-the-scenes magic going on to allow the Bind or Eval functions to obtain the values of an object based solely on the name and type of the object, so why can't I do this?