lordmilko
commented
10 months ago Hi @LPeter1997,
I understand this project is utilizing my ClrDebug library, and that it has based its current dbgshim resolution logic found in ClrDebug's NetCore Sample project. At the time this sample was written, there wasn't really any good way (that I could see) of easily acquiring a copy of dbgshim to ship with .NET applications, hence why this hacky FindDbgShim implementation was used.
You may be interested to know that in .NET 8, thanks to an issue which has been resolved, it will be possible to properly reference the Microsoft.Diagnostic.DbgShim NuGet package and have dbgshim be properly copied to your output directory (where previously MSBuild would have refused to copy dbgshim to the output directory on the basis it considered dbgshim to be part of the runtime itself)
Note that depending on the way your program is compiled, and the platforms you wish to support, all desired runtime implementations of dbgshim may not be copied to your output directory (e.g. compiling for and/or on Windows might only give you Windows dbgshim DLLs). You can work around this by adding an MSBuild task to reach out to your $(NuGetPackageRoot) and manually copy all desired runtimes to your output folder. ClrDebug's NetCore Sample has been updated to show this technique, and contains a sample DbgShimResolver implementation which may or may not be useful.
Regards, lordmilko
LPeter1997
reflectronic
Kuinox
Currently we have a couple of
FindDbgShimmethods lying around that stupidly tries to look up the default Windows path of the DLL. It is advised that we ship this DLL with our debugger. Let's do that and test the debugger on Linux. Affected components are everything that consumes the debugger API, so we should pack it with the debugger API.