Setting brakepoints and running in the debugger. The Dump Window could be used to Show debugging hints
The LINQPad integrated debugger is now in beta!
Kim Wu commented
Really !! ? :) :) :)
Will try it ASAP
Martin Kirk commented
This feature is freaking awesome !!
Thomas Levesque commented
> The LINQPad integrated debugger is now in beta!
Im embarrassed that this future takes the first place. come on people, you ALL want to bloat such a small and slick code editor with debugger? What comes as next? Visual studio project support? WCF config? Isn't your environment already dirty enough? Visual Studio Community is free! Take it instead
Michel Bretschneider commented
Would be nice if at least the line numbers in exceptions would match the line numbers given in the editor. Options are either offsetting the line numbers in the editor by the usings/declarations or provide the .cs used to compile the query.
Daniel Rubin commented
This is easy enough to do in code:
if (Debugger.IsAttached) Debugger.Break(); else Debugger.Launch();
But it would be much better if there were actually a toggle to automatically do this.
Brad Christie commented
you're supposed to be writing snippets in LINQpad. anything more than that (where you find debugging is necessary over and above `.Dump()`) should probably turn in to an application...
Martin Kirk commented
are you insane.. ??
I highly doubt it would be easy to pause execution, let alone display debugging information..
DUMP() is usually enough - if you want debugging capabillity, then install VS2009/12/13 on the machine
Ashton Lamont commented
Especially useful, if you need test some bug or feature on customer computer, where VS isn't installed.
Mark Johnson commented
Well, installing VS in production is out of the question. So having an integrated debugger would be very useful.
Just to add to this thread, you can add, at the beginning of your C# program:
if (!Debugger.IsAttached) Debugger.Launch();
This will allow you to select the debugger if you don't want to go through the "Debug... Attach..." through Visual Studio.
Also, make sure that in your "Advanced" preferences that you change the 'Execution' option for "Optimize queries" to "False". The source code LINQPad generates, provided you added the debugger break will not be optimized so you can view the state of all your variables in the debugger.
You already can do this. Add some code like this to set a breakpoint:
Now open a new instance of Visual Studio and from the Debug menu choose Attach To Process. Choose LINQPad and then run your query. When the code reaches your breakpoint it will break in the visual studio debugger.
uhh... never thought about this option. Quite obvious! Nice to have this option in the meantime.
This can actually be done by attaching VS to the LINQPad processing and having the following code in your query:
a lot of times I need to inspect some intermediate result by using dump, which is not very productive. support debugging duing the exection will be excellent.