I can attach the debugger and get it to break - but it has trouble finding the .cs file, I think LinqPad deletes it as part of its build.. 8-(
If you call
Debugger.Launch();
Debugger.Break();
to initiate the breakpoint within your LINQPad script, LINQPad will guess that you want to use VS to debug your script and won't delete the .cs file.
Start LINQPad
In VS, open Debug -> Attach to Process...
Choose LINQPad.exe
Set breakpoint in your code called by LINQPad C# code, or write Debugger.Break() in your LINQPad script where you want the debugger to halt.
Execute the script from LINQPad and watch the magic.
If your LINQPad code is calling a method in some referenced C# assembly and you want to debug that assembly in Visual Studio 2015, this worked for me:
Build your solution.
Optionally, run your LINQPad script, let it crash, etc. In the lower right LINQPad status bar, notice the PID in light blue coloring.
In VS, CTRL + ALT + P to attach to process. Attach to the LINQPad UserQuery process with the PID you saw.
Place a breakpoint here in VS.
Run the linqpad query and pop over to VS. You should hit your breakpoint!
Related
Want to debug an executable under debugger. How to do it in visual studio.
Windbg has an option of open executable. But I find this is missing in VS 2010.
The question is not exactly same as
Debug exe in visual studio 2010
as I am not really interested in image file execution to debug a start up.
Rather want to just debug the exe under debugger, once it is broken, want to
set some break points and understand the flow of execution.
Albeit image file execution is a workaround for this.
I am not sure if this question is naive; But this is a very straight line use case scenario, I find missing in MS VS 2010.
You did not specify it in the question, but I assume you do not have the source code. Just use File/Open Project/Solution, select EXE file and Open it. Then select Debug/Start debugging. The other option is to run the EXE first and then Select Debug/Attach to process.
If what your asking is how do you attach VS to the exe you want to run then you can follow these steps:
Run the executable
In VS navigate to Debug -> Attached to Process
Find your process created by running your executable and click "attach".
However, if the executable you are trying to run fails almost immediately or runs quickly and exits then you could try the following steps:
Set a debug point at the start of the code
Switch your build to Debug and run the application.
If your application is running in Debug, but failing when you execute the exe then you could try these steps to see if the your app will give more information in a console window or other.
Make sure your build is set to Release.
Navigate to Debug -> Start Without Debugging
If you have the source code, you can use Debugger.Launch();
You put it anywhere in your code, build the .exe and then once it gets launched (by Process.Start for example) and reaches Debugger.Launch();, a window will be asking you how you want to attach to the process.
Typically, you'll attach to some Visual Studio instance and it'll automatically pause the debugger where Debugger.Launch(); has been placed.
You can then open the project's files (File -> Open -> File...) and place breakpoints wherever you want.
As you know Visual Studio is an IDE and windbg is just a debugger.
I always browser code in visual studio and copy the method name then paste to windbg to debug.
I wonder could I set breakpoints in vs and then start windbg and it'll use the bp list in vs?
Not really, the problem is that when the bp is hit it raises an exception that the debugger quietly grabs and compares to it's list of known breakpoints. While it might be possible to have both debuggers attached, it would probably be a toss up of who got the exception first, also attaching two debuggers to the same process can cause odd behavior.
You cannot set breakpoints from both Visual studio and WinDbg, there can only be one debugger that is attached invasively.
You can attach invasively with Visual Studio and attach non-invasively with WinDbg but both cannot attach invasively.
Similarly if you attach invasively with WinDbg you cannot attach invasively with VS, the option will be greyed out for your exe.
I'm trying to debug tests from visual studio using nunit-console using a VS-macro, but I'm having issues when attaching the debugger / IDE to nunit-console / nunit-agent. I do have the macro working, if I just want to run the test, the issue is only when attaching the debugger.
I seem to have a deadlock issue of sorts. When I kickoff my macro, it freezes the IDE. After the attach, the test pauses at a break point (i think),but I cant see this, since the IDE is frozen. I cant stepthrough etc, since the macro is locking up the IDE, and I cant continue the test, since its halted at a breakpoint. Any ideas?
I cant use resharper / testdriven / extensions etc, no 3rd party, dont ask :(, so its the macro, something like it, or nothing.
Using Nunit 2.5.7, VS 2010, .net 4 projects.
What I have so far
process.Start() 'run nunit-console
If attachDebugger then
For Each debugProcess As EnvDTE.Process In DTE.Debugger.LocalProcesses
' no parent process ID on process type, so have to look at name for the agent.
If debugProcess.ProcessID = process.Id Or debugProcess.Name.Contains("nunit-agent") Then
debugProcess.Attach()
End If
Next
End If
process.WaitForExit()
DTE.Debugger.DetachAll()
It's just a guess, but I suspect that Visual Studio is running the macro on it's lonesome UI thread.
Perhaps you could try this:
In your Macro, spin up another thread and run the code you've written in that. Let the Macro exit immediately.
I am trying to attach VS2010 debugger to Linqpad so that when I use classes from my c# project I can add breakpoints and have Linqpad execution halt.
But this does not work, Linqpad happily executes and finishes without hitting my breakpoints.
Now, I read a bit on Linqpad and it executes every "query" in its own process, does this in any way fool VS2010 so that the process I attach to is not the one executing my objects?
And if that is the case, is there a way around this so that I can get debugging with Linqpad to work?
Found out that since Linqpad creates a new appdomain for each query window you cannot currently bind visual studio to it directly.
You have to set debugger.break() in your source code to trigger a request for opening a debugger.
This is not the best solution as it means I have to change the source back and forth and cannot use normal breakpoints but it works.
Found a better one my self.
You can not attach Visual Studio to LinqPad and at least trace the code in your VS project.
Unfortunately you cannot trace the linqpad part of the code thiw way.
If anyone should find a better solution, please share it with me.
Found a new thread with a better solution
How to debug LinqPad query in Visual Studio Debugger?
what is the difference between start Debugging and Start Without Debugging in Visual Studio while running a program ?
The first option starts the program under the control of Visual Studio's debugger. The second option starts the program stand-alone. Some of the practical differences while debugging a process are:
You can pause, resume, stop and restart the debugged process from Visual Studio.
Breakpoints defined in the code will be active for a debugged process, and the debugger will pause the process and show a stack trace whenever the process hits one of them.
You cannot exit Visual Studio without stopping the debugged process.
When a debugged console process exits, it will display a termination message until you press a key. This allows you to inspect the output of a just-ended process without having the console window immediately disappear on you.
The former attaches the debugger, the latter does not. You use the latter if you want to run in the same way an end user would.
the answer seems obvious, especially if you just try it :)
"Start without debugging" starts your app but doesn't attach visual studio as the debugger. "Start debugging" starts your app, with visual studio attached as the debugger.