fslaborg / flips

Fsharp LInear Programming System
https://flipslibrary.com/#/
MIT License
253 stars 32 forks source link

sourcelink all the things! #66

Closed baronfel closed 2 years ago

baronfel commented 4 years ago

If you follow the advice over at the dotnet/sourcelink repo and

Users will be able to go to definition in editors like ionide, and debugging sessions will be able to step into your actual library code regardless of editor choice. Pretty nice for like a two line change.

TysonMN commented 3 years ago

I think a better solution is to embed the source directly into the DLL. That is what we are doing in Elmish.WPF.

I don't know the tradeoffs, but here is my best understanding.

Embedding the source is simpler. It doesn’t require a network or internet connection. It doesn’t require any configuration to specify the location of the source code repository and symbol server. One advantage of Source Link is that you can give the same DLL to trusted and untrusted users and only the trusted users are able to use Source Link to obtain the source. This advantage doesn’t exist for an open source project, which definitely includes .NET Core and maybe even .NET Framework since reference source exists. Another disadvantage is larger DLLs, but I don’t know how much larger. I don’t expect that I would notice the difference in size. A possible disadvantage of embedding the source causes slower execution, but I am not sure about that. I certainly have never proved with benchmark tests that embedding the source causes slower execution.

baronfel commented 3 years ago

The primary question I have with this method is: Does go-to-definition work in a non-debug context when you embed the sources in the PDB? If so, I don't really care which way it happens. I just want to be able to go-to-def in my editor (Ionide), and I know for a fact that SourceLink enables this (because I implemented it ;P)

TysonMN commented 3 years ago

"Go To Definition" for something defined in a NuGet package doesn't work for the following combination of things

I have a very hacky workaround though. Suppose I want to go to the definition of a function that is called from my code. Then I set a breakpoint at the call site and execute that code (by either running the application or from a test). Then I "step into" the call, which opens the corresponding source file. This file remains open after I stop executing. Even with the file open though, trying to go to that definition doesn't work.

@baronfel, are you saying that the following setup allows you to go to definition?

baronfel commented 3 years ago

Yes, precisely. We have sourcelink support (and have for months) for debugging and non-debugging scenarios in VS Code for F# and C# sources (heck VB too for that matter, the actual backing source doesn't matter so much).

TysonMN commented 3 years ago

That is excellent. I am jealous. I feel like going to definition with F# in Visual Studio is broken in so many ways that it never occured to me that I should be able to see the source code for a function defined in a NuGet package with embedded source.

I will create an issue in the F# repo for this.

TysonMN commented 3 years ago

Do you happen to know if this setup allows go to definition?

My first attempt didn't work.

TysonMN commented 3 years ago

I will create an issue in the F# repo for this.

Before I do though, I want to make sure I understand the problem and can communicate it to others. I created this issue in a project I maintain to investigate this further.

baronfel commented 3 years ago

@TysonMN make sure you're following the steps at https://aaronstannard.com/visual-studio-sourcelink-setup/ to ensure your VS environment is set up correctly. I'm not at all knowledgeable about what VS does here, it's not an editor I use at all.

TysonMN commented 3 years ago

Thanks so much for the link! You have been exceedingly responsive and helpful. I am very grateful :)