How to access locals through stack trace? (Mimicking dynamic scope)

Question

Background

Even though it\'s possible to compile C# code at runtime, it\'s impossible to include and run the generated code in the current scope. Instead all variables

Answer 1

This isn't possible. In the compiled .NET code (intermediate language), variables are represented simply as indices on the stack. For example the ldloc instruction, which loads a value of a variable takes only an unsigned int16 value as the parameter. There may be some way to do this for applications compiled in debug mode (after all, when debugging application, Visual Studio does that), but it cannot work in general.

In Phalanger (PHP compiler for .NET, which I'm partly involved in), this had to be somehow solved, because PHP language has eval (it doesn't need to provide dynamic scoping, but it needs to access variables by name). So, Phalanger detects if a function contains any use of eval and if it does, it stores all variables in Dictionary<string, object>, which is then passed to the eval function (so that it can read variables by their name). I'm afraid this is the only way to do this...

Answer 2

So my question is whether it's possible to mimic dynamic scope in .NET through the use of reflection.

Reflection enables run-time manipulation of items which are expressed in the metadata of an assembly.

Local variables are not items expressed in the metadata of an assembly.

The answer to your question is therefore "no".

(How) is it possible to reliably access the locals of calling methods?

A device which accesses the locals of a calling method is called a "debugger". So the answer to your question is "write yourself a debugger".

Note that debuggers do not reliably access locals in a world with code optimizations. Locals can be optimized away, the jitter can generate code which uses the same register for two different locals, stack frames can be re-used during tail calls, and so on. And of course, you'd better have the PDB file that tells the debugger what the names associated with each stack frame location are.

What your method would have to do is start up your custom debugger as a new process, and then wait for the debugger to send it a message. The debugger would then suspend the threads of the original process, do the interrogation of the stack frames, and then resume the threads of the process. It would then send messages to the debuggee that contain the information you've discovered. Since the debuggee is sitting there in a wait state waiting for the messages, it would then resume its business.

If what you want is an in-process "eval" capability, consider JScript.NET, a language that was designed for that sort of thing.