The first test seemed obvious: I was using the release build of the dynamic dll, so I thought that some optimizations might have gotten the source and the executed code out of sync. Therefore, the first test was to switch to using the debug build, without optimizations.

At first, I just switched to the debug build. This did have some impact, as I was able to set a breakpoint on the line after the if statement, but the breakpoint was never reached, even though the code it was on had clearly run (the tooltip would be nearly empty had it not run, and it was nowhere near empty).

That was a bit of an improvement, but not much, since my real objective was to step through the code that was building the tooltip, and while the tooltip WAS being built, and I now COULD set a breakpoint, those breakpoints were ignored, which meant that debugging was impossible.

I then started writing this post, and realized that what I said in the first line I had not confirmed: I knew I had switched to the debug build, but I didn't know the state of the Enable Optimizations flag on the Compile tab of Project | Properties. Normally, that flag is clear for debug builds...but I thought I'd go check. Sure enough, it was checked for the debug build in this dll. Not sure why, not sure how, but I unchecked it and rebuilt.

Now everything is working the way I expect it to.

So, from this little sequence: Enable Optimizations MAY cause debugging to behave incorrectly. Execution MAY appear to take the wrong path at conditionals, and MAY appear to exit methods early, thereby skipping code that is actually run. This won't normally happen, so the debugger is normally reliable, but as long as optimizations are enabled, the debugger is not necessarily showing an accurate and correct representation of what the execution is actually doing.

Ultimately, this is probably a visible manifestation of something that is otherwise a good thing. The source says one thing, the debugger follows something which ideally is the source, but optimizations can mean that the execution path no longer lines up with the source all that well. At that point, the path that the debugger takes may not match the source very well at all. You want the optimizations, ultimately, but while debugging you really want the debugger to match the source perfectly, so you need to have the optimizations off.

This was never a thing in VS2010 (and I have no relevant experience with the versions between 2010 and 2019), which may indicate a change in the debugger, but more likely means that the optimizations that take place in 2019 are considerable, while the optimizations that took place in 2010...may not have been much of anything.