Theodoros Chatzigiannakis has an excellent answer, but I thought I might clarify a couple points.
First off, indeed, the C# compiler generates different code depending on whether optimizations are turned on or off. With optimizations off, locals are generated explicitly in the IL. With optimizations on, some locals can be made “ephemeral”; that is, the compiler can determine that the value of the local can be produced and consumed on the evaluation stack alone, without having to actually reserve a numbered slot for the local variable.
The effect of this on the jitter is that local variables which are generated as numbered slots can be jitted as specific addresses on a stack frame; those variables are considered to be roots of the garbage collector, and they are typically not zeroed out when the C# compiler considers them to have passed out of scope. Therefore they remain roots for the entire activation of the method, and the GC does not collect anything referred to by that root.
Values which merely go onto the evaluation stack are much more likely to be either (1) short-term values that are pushed onto and popped off of the thread’s stack, or (2) enregistered, and quickly overwritten. Either way, even if the stack slot or register is a root, the value of the reference will quickly be overwritten, and therefore will no longer be considered reachable by the collector.
Now, an important point is implied by this description of the jitter behaviour: the C# compiler and jitter can work together to lengthen or shorten the lifetime of a local variable at any time at their whim. Moreover, this fact is clearly stated in the C# specification. You absolutely cannot rely on the garbage collector having any particular behaviour whatsoever with respect to the lifetime of a local.
The only exception to this rule — the rule that you can make no predictions about the lifetime of a local — is that a GC keepalive will, as the name implies, keep a local alive. The keepalive mechanism was invented for those rare cases where you must keep a local alive for a particular span of time in order to maintain program correctness. This typically only comes into play in unmanaged code interop scenarios.
Again, let me be absolutely clear: the behaviour of the debug and release versions is different, and the conclusion you should reach is NOT “debug version has predictable GC behaviour, release version does not”. The conclusion you should reach is “GC behaviour is unspecified; lifetimes of variables may be changed arbitrarily; I cannot rely on any particular GC behaviour under any circumstances”. (Except as mentioned before, a keepalive keeps things alive.)