I've started researching some ideas in algorithms using VS2010 and F# interactive.
So, I've created a DebugScrip开发者_Go百科t.fsx
, I write some code there and eventually send it to F#Int to test it.
At some some moment I need to catch a bug. But I can't place a breakpoint even in a simple for
loop:
for i in stringarray do
printfn "%s" i
When I press F9 to set a breakpoint, the VS show a red circle with a warning sign. The hint for it is "The breakpoint will not currently be hit".
Surely, I did open Debug menu -> Attach to process ... -> Fsi.exe previously
I tried placing Debugger.Break()
inside the loop, but that's the only line where debugger stops, giving me no option to proceed with debugging lines inside the loop. I also don't have any local variables available :(
Maybe I'm missing something obvious?
in VS2015 is now much more easy: in Tools->Option->F# tools -> F# interactive-> Debugging -> Enable script debugging = True
then reset your interactive session and when you want to debug press CTRL+ALT+D and send command as usual
(or right click on the source file and choose "debug in interactive")
You cannot debug the code that is part of your scripts, but you can debug external code referenced in your scripts by attaching the debugger to the Fsi.exe process as you describe. So if you really want to debug from the interactive window without wanting to write a console program, you can create an fs file with the function to debug and:
Attach the debugger
Either
- reference the fs file with #load (*)
- compile the code as a library and reference the resulting DLL with #r
Set a breakpoint
- Call the function from a script
(*) worked on my VS Ultimate installation, but I haven't been able to reproduce on another machine with VS Shell install
As far as I know, there's no way to do this. Instead, you'll want to use a .fs file and start debugging it in Visual Studio instead.
In addition to kvb's answer: One could say that F# Interactive is already a type of debugger. You can feed code line by line (or region by region) and see intermediate results. You can also inspect the value of bindings just by evaluating them in the F# Interactive console.
the interactive is for feeding it small pieces of code and evaluating intermediate results, think of it as micro-unit testing. i've had some success with using nunit with f#, it's no different than with c#, you decorate your testfixture and test cases in the same way and it will load up. i did have some issues with mixed-mode assemblies where nunit would barf, but overall, it's a better way imho to test a piece of code. also, i did not see a way to send a namespace to interactive, only modules.
精彩评论