Well, it wasn't quite as simple as that, as it turns out.

While changing that setting did allow me to see the code, and step through it, as far as I have seen to date, you can't see all variables. In fact, it may be that you can't see MOST variables if you are referencing the release version. I have yet to test this out for dynamically loaded plugins, but I had this simple construct:
Code:
For each fl As String in AllTheFilesInSomeDirectory
  'Do something with fl.
Next
That's not precisely correct, but it's close enough. Basically, this was part of the code that loaded plugins, so it was looking at all the .DLL files in the folder and examining the objects of each one in turn. There was an issue with one of them, so knowing which one would have been very useful. Since fl was the name of the file, seeing fl would have been pretty handy, but fl couldn't be shown. The reason for the refusal was that fl either wasn't available, or might have been optimized away.

Now, it certainly was in scope, because I was inside the For loop. I also don't think it could have necessarily been optimized away, but I'm not completely certain about that. It may be that one of the optimizations is that such a local variable doesn't truly exist. The optimization might have been to create the list of values on the stack and just used a pointer to the current value rather than moving the current value into a local variable. So, I can't rule out the possibility that fl really WAS optimized away. However, that seems to be the reason given for not showing me pretty nearly EVERYTHING when stepping through the code in any referenced dll.

In 2010, there were times when you wouldn't get to see local variables unless they had been declared at the top of the method. This generally happened only when you were a couple calls deep into a dll, and never seemed to happen when just one call deep into a dll. If it really mattered, the solution was to declare all such variables at method scope. In other words, in the preceding example, I'd have to have a Dim fl As String up at the top of the method, and then I'd be able to see the value while in the loop. Since this was a rare issue that only made a difference in even more rare circumstances, it generally wasn't worth bothering with.

In 2019, it doesn't matter whether fl is declared in the loop or at the top of the method, I can't see the value in either place. As I said before, the message denying access to the value may be completely correct in that it may have been optimized away, and therefore the variable doesn't even exist to be shown. Working with the debug version solves the problem for referenced dlls, and I have yet to explore how it works for dynamically loaded dlls.

To some extent, this is what I expect. After all, you can't debug a release version, so why can you step through a referenced release version in 2010? Using all debug versions does make more sense, I was just really happy to not have to deal with versions for referenced or dynamic dlls in 2010. Now, it appears that I DO have to deal with the build version.

So, I guess my question is: How to deal with this? I haven't seen a setting that says, in effect, "use the debug version of referenced dlls when in debug mode, use the release version of referenced dlls when you do a release build." That is clearly impossible to do in most cases, since most cases will use third party dlls for which only the release version is available to you, but for my own dlls, it seems like this should be possible.

The second half to that is the dynamic dlls. For testing purpose, I could always use the debug builds. All I'm doing is manually copying from the bin folder to a different, common, folder, so I can just as easily copy from bin/debug as from bin/release. Still, it seems like there might be a better way to manage this. On the other hand, the more I think about it, the more I realize that this really isn't an issue for dynamic dlls, because I really CAN always work with the debug versions, and the release versions would rarely be dealt with.