[RESOLVED] Annoyance with VS2019

I've been using VS2010 for working on a plugin system. The main project references a few of my own dlls (three or four), and everything else is dynamically loaded plugins. I recently moved to VS2019, and can't go back because I updated some technology that requires at least FW 4.5, so VS2010 is out of the question.

In general, I like VS2019, but there have been a few annoyances. When adding references, the recent list is always empty for me, though others say it works fine for them.

Unfortunately, a newer annoyance just seems ugly, for my situation: In VS2010, you could step into the source of any dll, referenced or not, and the version (Release or Debug) didn't seem to make any difference. That never made sense to me, as I don't see why I could step into a release version, but what has to happen to be able to step into dynamically loaded dlls is even more impressive. That behavior has changed with VS2019. Regardless of whether the main program is in release or debug, I can't step into a dll that was built to release version. I have yet to try this for the plugins, but I fear that it will be the same case.

This makes no sense to me, but it will be particularly painful. I reference a dll of my own making, and whether I reference release or debug determines whether or not I can step into the source code. That means that everything has to be built as debug versions to allow for debugging, and then everything has to be changed over to release versions at some later date. That's annoying, but it's only a few dlls. However, if the same is happening for plugins (which I currently can't test), the situation becomes FAR worse because there are dozens of them.

It clearly doesn't matter all that much, since VS2010 allowed you to step into the source regardless of version. Showing the source for release versions is insignificant beside what has to happen to allow stepping into plugins. Is it really no longer possible? That would be a significant step back in utility for VS, in my case.

If it is the case, how does one simply toggle back and forth between the versions? If the main project is in debug, I want the dlls to also be in debug. If the main project is in release, I want the dlls to also be in release. When it comes to the plugins, that's a different matter, as they are all just found in some folder in the Documents. They aren't necessarily associated with the projects that built them, so the very fact that VS2010 allowed stepping into that code meant that it had to note the name of the DLL, note that a project existed on the same computer which built such a dll, and assume that the source in the project was the source for the dll. To some extent, that's not quite as impressive as it sounds, as the dll will have a fingerprint that will match exactly to the project, but VS is making quite a leap to go from a dll sitting in a folder to a project sitting somewhere else on the HD and just step right on into the source code. If I now have to deploy all debug plugins just because VS has decided to become pedantic in it's old age, that's a problem for me.

Try this. Go into Options -> Debugging -> General and clear the "Enable Just My Code" option.

That did solve it. I tested it incorrectly, at first, but recognized my mistake and did the proper test.

That's a big relief.

I think you're going to find that a lot of changes between new Visual Studio editions over their predecessors are just changes in various default settings.

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.

Quote:

---

Originally Posted by Shaggy Hiker

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.

---

Hmmm....try this. When you set your config to compile to the release version, go the project properties -> compile -> Advance compile options and set generate debug info to full. I don't know for certain that this will help you but it's the first thing that came to mind when I read this.

This setting is one of the differences between compiling to a debug version and a release version.

That's a good idea, I'll try that...tomorrow. I had some fear that I would need pdb files. That is readily available for referenced dlls, but not for dynamic dlls. They haven't appeared to make any difference though.