Is Sourcelink support set up correctly right now?

[paralaxsd]

Hi,

I'm currently debugging an issue where dropping a file into a Silk.net window will randomly but often lead to an ExecutionEngineException originating from Silk.NET.GLFW. While doing that I wanted to drill down into the call stack to pinpoint the exact place where it happened. My assumption was that I could get a view into the original source code since the nuget packages have been set up to support Sourcelink.

I can't get it to work though. With 'Just My Code' disabled, and Sourcelink support enabled in latest Visual Studio 2022, loading symbols for a Silk call stack frame fails. The nuget package itself does not contain any symbols or source server information and so the only option I'm given is to decompile the release code itself, with obviously much worse results.

I'd be grateful on any pointers :)

[Perksey]

Truth be told, none of us really know. We've tried fiddling around with it for a long time, and DotNet.ReproducibleBuilds is supposed to be the magical package that sets it all up for you. We'd welcome any contributions because we don't know how to set it up properly!

As for the ExecutionEngineException, at a guess it's something to do with delegate marshalling, possibly a regression from #821. Keep an eye on glfw.GcUtility to see what it's caching - it could be that your delegate is being freed prematurely.

[paralaxsd]

Got it. I guess I'll look into it then, set up an example project first and let you know how it turns out!

[dnperfors]

It might be needed to upload the snupkg (or something similar) as well. I can't easily see if these are actually generated.

[Perksey]

No it isn’t. We welcome the community to contribute fixes to the SourceLink setup as we couldn’t figure it out. You can test sourcelink by setting a package prefix in common.props and using the “nuke pack” command to generate the artifacts. After that, push it to NuGet (using the prefix you setup earlier)