This sounds like a bug on netcoredbg. AssemblyLoadContext.LoadFromStream should work as it does in Microsoft's debugger.

As I understand it from reading the issue you linked, netcoredbg is unable to find the PDB file when using the AssemblyLoadContext.LoadFromStream overload that only takes the assembly stream (the DLL). In this case, they try to find the PDB file name from the DLL and if it doesn't contain it then they can't find it.

I haven't checked but I'd imagine the DLL built from Godot contains the PDB file name, so they should be able to find it. But even if it didn't contain it, we're not using that overload. We're using the overload that takes the assembly stream AND the assembly symbols stream (the PDB), so we're already providing the PDB. This case (our case) should work, and if it doesn't then it's a bug on netcoredbg.

There's also a linked PR (Samsung/netcoredbg#108) that seems like it fixes the netcoredbg bug, so I suggest waiting for that instead. You could try that branch and see if it fixes the issue for you.

As for why we are using AssemblyLoadContext.LoadFromStream, if you read the comment: we're loading in memory to prevent locking the file.

I agree that the netcoredbg branch is probably the better option if it gets resolved, but reading through it, I do see that it's pretty stale.

Are we sure that LoadFromAssemblyPath locks the file? I couldn't find anything that says it does. Even took a quick glance through some of the code in the dotnet repo and nothing jumped out at me.

AFAIK it's a Windows thing not specific to LoadFromAssemblyPath that happens whenever you open a file handle (which naturally this method does). But I don't use Windows so I can't check. It seems GDExtensions have that issue right now:

• Locked PDB file blocks GDExtension compilation when Editor is launched within debugging #82536

I just created a new PR(Samsung/netcoredbg#164) which should fix this issue. I do believe the netcoredbg route because it was unable to read in-memory module symbols. msdbg does not.

@granitrocky The changes have been implemented so you can try the latest version of netcoredbg.

@thanikTheDev Thanks! I'll try it out and if it fixes the issue I can close this PR.

@granitrocky Can you confirm that this was fixed upstream?

@raulsntos I can confirm that the latest netcoredbg works. I will close this issue.

@granitrocky Would you clarify how you were able to get netcoredbg working, which IDE you used, and whether or not it works in VSCodium? Per our conversation in Chickensoft, it sounds like it does not work from VSCodium, and I am wondering if there is a relevant bug on the VSCodium side of things (I was unable to find one). I tried using the latest VSCodium with the C# extension that uses netcoredbg, and it simply quit without any errors in any of the logs.

I used the netcore emacs package along with dap-mode. I did have to manually change the command line that was invoked to include a path to godot on the netcoredbg invocation. I imagine there's a better way to do that, though.

This does seem to be a VSCodium related problem and not netcoredbg or Godot

VSCodium/vscodium#82

I used the netcore emacs package along with dap-mode. I did have to manually change the command line that was invoked to include a path to godot on the netcoredbg invocation. I imagine there's a better way to do that, though.

This does seem to be a VSCodium related problem and not netcoredbg or Godot

VSCodium/vscodium#82

I think either you or me, are misreading something :)

Apart from the "easy way" not working anymore, that post you linked seems to indicate precisely how to make it work. In fact is the current recommended approach by vscodium team. Its only in godot that we are having issues.

Edit: my bad, apologies. It seems I was focusing in that issue OP, but missing crucial parts of the conversation going on there.