Allow F# code in “Watch” and “Immediate” windows

[ghost]

Overall question: can we improve the debugging support for F# code via the Visual F# Power Tools?

[ovatsus]

This would be great! Another related issue is that in match expressions, if there's a breakpoint in the handler of the first match, the VS debugger always stops there even if that match isn't hit

[jaredpar]

Given the current architecture of Visual Studio this would essentially require writing an entire Expression Evaluator. Doing so is a massive under taking. This is doubly true for F# because a) it would be written in F# (managed code) and b) has heavy use of lambdas which are hard to work with in the current EE architecture.

I won't harp on the details too much here but here is a quick summary.

Managed code is a problem because the EE architecture is based heavily around the COM apartment model. UI is all in the main STA while the actual EE component is in the MTA. Correct execution of the debugger relies on strict compliance with this model by the EE. Managed code throws a wrench in here because the CLR happily violates COM apartment rules (or more specifically, makes it very hard to create an object that exists only in the MTA or STA). It is possible to make this work (did this once as a sample) but adds yet another layer of complexity.

Lambdas in the EE are problematic because it requires code generation from the EE and injection into the target process. Difficult and not always possible depending on the circumstances. I've written about this before here

• http://blogs.msdn.com/b/jaredpar/archive/2009/08/26/why-no-linq-in-debugger-windows.aspx
• http://blogs.msdn.com/b/jaredpar/archive/2010/06/02/why-is-linq-absent-from-debugger-windows-part-2.aspx

Again this is possible to do but requires a good amount of effort.

Another option languages often want to explore is to layer their EE on top of the existing C# EE. Essentially write an EE that is just a pretty presentation layer on top of the C# EE. Hence no heavy lifting needed just pretty printing. Unfortunately the EE architecture is just not setup to do this. It's attractive at a glance but the details are very messy and it becomes almost as complex as just writing your own from scratch.

Hate to be a downer about this subject but unfortunately it's something I have a lot of experience with it. I rewrote the VB.Net EE in 2010 from scratch and since then I've been the point contact for customers who are looking to do exactly what @dsyme stated in the premise of this issue. I've helped customers through writing an EE from scratch (the undertaking is usually on the order of years) and thankfully convinced several others to not try.

There is a good level of demand for something like this in Visual Studio though. I'm hopeful that a newer version of Visual Studio will make this process easier because it's a shame that languages like F# can't be awesome in the EE too :(

[dungpa]

What a horror story. Thanks @jaredpar for the insights.

Given our limited resources and lack of experience on EE, it's unlikely that we can implement this and #200 in a short timespan. I'm closing it.