9

I call function in .NET using Reflection (Method.Invoke). If an error occurs inside this method and exception is raised, debugger doesn't show actual code but stops at Invoke() call. I can retrieve exception information from InnerException but this is very inconvenient, compared to regular debugging with callstack available and so on. Can methods invoked using Method.Invoke be debugged like regular function calls?

JaredPar
  • 733,204
  • 149
  • 1,241
  • 1,454
John
  • 2,295
  • 1
  • 20
  • 25
  • @Pawcio - why this bounty? (you'll never find a more "reputable source"...) – Simon Mourier Mar 23 '21 at 18:34
  • Don't know what you mean by "reputable source" but the answered were not really answered, and I wonder if it's even possible as this debugging behavior is very annoying. – Pawcio Mar 24 '21 at 13:42

3 Answers3

10

What you're liking hitting is the "Just My Code" feature. The debugger by default limits debugging to code which is deemed authored by the developer. This reduces a lot of noise that would be present in say debugging a WPF or WinForms launch.

In order to have items like the Exception assistant run for all code you should disable Just My Code.

  • Tools -> Options
  • Debugger
  • Uncheck "Enable Just My Code Debugging"
JaredPar
  • 733,204
  • 149
  • 1,241
  • 1,454
  • 2
    Unfortunately, "Enable Just My Code" was already unchecked. But it seems irrelevant as both caller and callee are in fact my code. – John May 16 '11 at 23:30
  • 1
    @John, that is odd. My next step would be to turn on "break on throw" for all exception types and see if that dumped me where i expected. That won't solve your issue but it will take us one step further. – JaredPar May 16 '11 at 23:33
  • That's very weird, after turning "break on throw", I'm getting FileNotFound exception for XmlSerializer assembly that failed to load. Without "break on throw", everything works fine. – John May 16 '11 at 23:39
  • @John, that particular exception is usually a red herring. If you hit "Continue" it should move onto the next one. – JaredPar May 17 '11 at 03:35
  • it's useless, there is a way too much noise using this method. – John May 24 '11 at 14:54
  • The question and answer did not mention the version of VS, but it works for me in VS 2012 with some issues: debugger always stops on the 1st breakpoint in the dynamically invoked method, but then it starts skipping the breakpoints, so I also have to resort to @CodingWithSpike's answer further down. – ajeh Jul 04 '16 at 15:29
5

If all else fails, you can also put something like this into the method that gets invoked:

#if DEBUG
    System.Diagnostics.Debugger.Break();
#endif

That will basically "programatically" cause a breakpoint there.

You could also make it slightly better by doing:

  if(Debugger.IsAttached)
    Debugger.Break();

So that it will only break if you are actually running it in the debugger.

Edit:

On 2nd thought, if you have the code to edit it, then you can probably just stick a regular breakpoint there through VisualStudio. I guess my answer doesn't make sense... sorry :)

CodingWithSpike
  • 42,906
  • 18
  • 101
  • 138
  • 1
    Your answer makes perfect sense, see my comment to @JaredPar's answer as well. I was facing issues with the breakpoints being skipped and your method worked. – ajeh Jul 04 '16 at 15:31
0

My workaround is to create Timer and call method inside Tick():

GUI code -> call function via Method.Invoke -> function setups a Timer -> in Tick there is function body

Unfortunately it's not very pretty (and not suitable in some cases)

John
  • 2,295
  • 1
  • 20
  • 25