showing C# method return in debugger – VB.NET can do it!

Last time I mentioned that I’d like the ability for the C# debugger to show the return value from a method.  One thing that some threads on the subject in various places (including StackOverflow) seem to argue is that the CLR doesn’t support this, so the C# debugger can’t do it.

For instance, this response (which admittedly is coming up on 2 years old):

Unfortunately cluttering your code with temporary variables in the only way in managed code (C# or VB). The CLR has no support for "managed return values" in the debugger and hence VS does not either.

Since it’s a very simple test to show this to be false (at least in 2010 / .NET 4), I figured I’d include it in a post.

For this exercise, I’m using Visual Basic 2010 Express and Visual C# 2010 Express so anyone else should be able to reproduce this (for free) themselves.

In trying to keep the example simple, I just picked a method that would return something that would obviously change from call to call and couldn’t be pre-calculated (so the value being shown couldn’t be something from a different/separate call).

The C# code:

using System;

class Program
    static void Main(string[] args)
        int multiplier = new Random().Next(10);

    static long Foo(int multiplier)
        return DateTime.Now.Ticks * multiplier;

The VB.NET code:

Module Module1

    Sub Main()
        Dim Multipler As Integer = New Random().Next(10)
    End Sub

    Function Foo(ByVal Multiplier As Integer)
        Return DateTime.Now.Ticks * Multiplier
    End Function

End Module

The key screen shot is setting a breakpoint on the ‘end function’ line and looking at the Locals window. 

With VB.NET, the function name shows up as an entry in ‘Locals’ and the debugger shows us the value it’s returning!


The C# debugger has no such support, though – at the same ‘end of method’ breakpoint, only the parameter passed in is shown:


So, clearly the CLR has enough support for the VB.NET debugger to support this feature, which would seem to be a pretty strong argument that the C# debugger certainly could implement this feature.