How to debug non-LinqPad code?

sgmoore

With older versions of LinqPad, you could attach the Visual studio debugger and step through, not just your LinqPad script but also through your code in other dlls.

With the new integrated debugger, I can't seem to find a way to step into the code in other dlls and System.Diagnostics.Debugger.Break() doesn't allow me to attach to Visual Studio any more.

Does anyone know a way of doing this?

DavidCornish

I came up against the same issue. I now temporarily change 'Run each query in its own process' in advanced preferences to false (doesn't require a restart despite the warning) to allow me to attach in Visual Studio and then when I've finished, put it back to 'true' again so I can debug other queries in Linqpad. Not ideal, but a workaround if nothing else.

JoeAlbahari

Another solution is to attach to LINQPad.UserQuery.exe instead of LINQPad.exe. The process ID is shown in the bottom right of the statusbar.

You will need to ensure that the LINQPad debugger is not also attached. To do this, uncheck the toolbar buttons 'Break when exception is thrown' and 'Break when exception is unhandled' and make sure there are no breakpoints.

JFalcon

The best solution I've found with the latest version (beta), is not to use the System.Diagnostics.Debugger.Break(), but instead, in your LINQPad script, add System.Diagnostics.Debugger.Launch().

When it hits there, you'll get the typical dialog asking you which instance of Visual Studio to debug with, and select the one with your open project. Provided you have built your project that your query is referencing, it will respect any breakpoints you have already set.

sgmoore

That works great.

Thanks.