RefEmit does not have the desktop api MarkSequencePoint

[KevinRansom]

In FSI we use ILGenerator.MarkSequencePoint to enable debugging of generated code from the in-memory generated assembly.

Will this be added back, and will debugging coreclr code enable it to work correctly once it has been?

// @jkotas, @dsyme, @joshfree, @steveharter

[danmoseley]

The only active ref emit API port issue I know of is https://github.com/dotnet/corefx/issues/12055

[danmoseley]

@jkotas this looks like another case of just expose in contract and add tests - do you believe it's more work than that? Any reason I shouldn't do this?

As we noted elsewhere, there is a lot of Ref.Emit present in S.P.Corelib that is not exposed in contracts, and I believe we planned to make strategic changes only this release.

[jkotas]

Adding symbol/debugging support for reflection emit is a large (likely months) workitem. This is not a simple expose and add tests. The tests added for this would need to be debugger tests.

[danmoseley]

OK. Deferred.

[steveharter]

Linking #15704 since that has a discussion on saving IL potentially with debug information.

[dsyme]

Just to say we're really missing this in F# land, as dotnet fsi is not emitting debug symbols. This affects both debugging of scripts and stack traces

[snuup]

F# script debugging, as it is possible with .Net 4.8 is incredible helpful. Such scripts are not just simple bash like admin "scripts" but much more the birthplace of very difficult code, where data analysis grows into algorithms. Being able to debug at this stage is an incredible cool feature.

See also dotnet/fsharp#5457 (comment)

[jackfoxy]

First thing I did after installing VS 16.9.1 was enable Use .NET Core Scripting. It took me a while to discover this disables breakpoints in FSI.

[zyzhu]

I second @snuup's comments about importance of debugging in data analysis scripting. Without this feature, scripting F# in Visual Studio will be a far inferior experience compared to debugging R in RStudio, debugging Python in PyCharm or VSCode, or debugging MATLAB.

In addition, it will be a blocking issue for supporting debugging break points in Jupyter Lab through dotnet interactive kernel. dotnet/interactive#320

[steveharter]

Keeping for future; once we have AssemblyBuilder.Save then we should consider.

[smoothdeveloper]

Also suffering from no debug in FSI, for exactly same reasons as @snuup. (dotnet/fsharp#15820)