Ultimately, this arose from a different oddity, which isn't really an oddity with VS 2019, but with 2017 and 2010, both of which I used for this project in the past. VS 2019 acts the way I feel that it should act, the others didn't...and I really appreciated that, though I didn't understand it.

One of the truly amazing features of VS is the fact that you can step into code from different projects, even if that code is not directly referenced by the project you are debugging (though with a few limitations, of course).

In my case, the main project loads dlls dynamically (plugins). Those dlls that it loads dynamically are just located in some folder. The folder isn't related to any project folder, or anything like that, it's not a folder in My.Documents, but it might as well be, so anybody reading this can think of it as just a folder in the documents folder. I used to manually copy the plugins from the project bin/Release where they were created into that destination folder (I've since automated that, because there are just too many plugins).

When running the main project, it opens each dll in that folder, sees whether it contains objects that implement certain interfaces, and if so, creates an instance of the object.

I've always been amazed that I can be debugging the main project and step right into the source code for those dlls. That source code isn't in the dll, especially not in the release version, and the dll in the folder has to be the up to date with the version in the bin/release folder of the project that created it, but so long as it is up to date, VS will happily step right into the source code for it. That means that VS is essentially saying, "here's a dll...let's see, here's a VS project that has output the same dll with the same signature...so I'll assume that the source code is there, as well, and step right on into it."

That's impressive. What's always been even more baffling about that is that I was always able to do that with the release version, not the debug version, of the code. Presumably, the release version optimizes away a bunch of stuff such that there isn't necessarily a one to one correspondence between source and compiled code. There SHOULD be lines in the source that aren't meaningful in a release version, but up until 2019, it made no difference at all whether I had the release or debug version of the dll.

That has changed, and that change was the source of this thread, because I was able to step into the release version of that base dll, but the instruction pointer in the debugger wasn't on the right line of code, and some critical variables were not available for me to see, which combined to hide the actual problem.

I'm not sure what changed between 2017 and 2019. It makes debugging a bit worse, but it's also considerably more rational. One shouldn't be able to step through a release version as if it were a debug version. If you could do that, then what are optimizations for?

Anyways, that's just a rant. If anybody has some insight into that change, I'd be interested in reading it.