Evgeny Morozov

I'm a bit surprised more people don't run into this. I had a go at debugging it. It seems to be due to the FileSystemWatchers created by various FileSettingsCache objects,...

Interestingly, if I run `setclrpath` immediately upon attaching LLDB (rather than after other SOS commands) I get a different error: ``` (lldb) sethostruntime "/path/to/my/self-contained/app" Using .NET Core runtime (version 0.0)...

@mikem8361 Yes, libcoreclr.so has loaded. The process was already running before LLDB was attached to it. @hoyosjs Thanks! OK, so with `setclrpath /path/to/my/self-contained/app` _before_ `sethostruntime` running `clrstack` works, but `sethostruntime`...

Also, this _is_ a regression - what I tried to do (sethostruntime to the app's dir, no setclrpath) works on Ubuntu 22.04.5 with lldb 14.0.0, .NET SDK 7.0.410: ``` lldb...

OK, so the fact that it worked with .NET SDK 7.0 with `sethostruntime` pointing to a .NET 8.0 self-contained app was a happy coincidence, I guess. But why is SOS...

Alright, so I have to script finding the runtime somehow. I hope you can see how all this is totally not intuitive from the point of view of a user...

Looking at the code in https://github.com/nunit/nunit3-vs-adapter/blob/f3b5c9c27490eb81340e09794624aea4d92cf5fe/src/NUnitTestAdapter/NUnitEngine/DiscoveryConverter.cs#L202 it indeed checks for concrete TestFixture types and throws for derived types.

In this case I can work around the issue by creating a normal `TestFixture` and setting `MaintainTestOrder = true` using Reflection, but that is, of course a hack, and NUnitTestAdapter...

Maybe! I'd like to, but now that we have a workaround, I'm not sure when I will get around to it.

@OsirisTerje I debugged this a bit, and it seems that it's not that simple. The discovery XML contains `