VS Complaint

I work with dlls. LOTS of dlls. I've got a couple other threads on here about complaints I've had with VS2019, but now I've encountered one that is intolerable.

I was debugging something and stepped into a method that was in a dll directly referenced by the main project (most of my dlls are dynamically loaded). The code stepping was terribly incorrect. It was appearing to take paths that it clearly wasn't taking, such as stepping to return statements in the wrong branch of conditionals, then stepping on into the next condition as if the last one hadn't happened...which it clearly hadn't, since it shouldn't have been in there and the return statement didn't execute.

I felt this might be because I was referencing the release version rather than the debug version, so I switched over to referencing the debug version...and all objects defined in the dll became undefined. I tried rebuilding, but that did nothing. Then I noticed that the dll in the bin\debug folder was roughly a third the size of the dll in the bin\release folder, and some other things that were in the bin\release folder, such as resources, weren't in the bin\debug folder at all.

My next step was to delete the obj and bin folders and rebuild the whole thing. This time around, while VS said it was building in debug, the bin\debug folder ended up completely empty. The bin\release folder rebuilt correctly. Nothing I have done will get VS to build a debug build. It says it is, as it shows the building graphic, and says rebuilding down in the lower left status area, but nothing results from it.

So, I couldn't link to the debug build if I even wanted to, and stepping through the release build is too erratic to be meaningful.

At this point, I'm going to uninstall VS and reinstall. After all, there are other issues, but they show up on both computers that I have VS installed on. The most notable one is that the "Recent" list of dlls referenced remains stubbornly empty, so I always have to browse for any dll.

There are other issues, as well, and I'm not optimistic that the reinstall will fix them, especially since I have VS 2019 on three computers, and issues appear on at least two of them (I haven't looked for the issues on the third).

I guess I'm just not impressed with the stability of VS2019 and am just venting that frustration, but if anybody has any suggestions as to how to improve things, let me know.

Still not sure what to make of the reluctance of VS to build that debug build, but after the reinstall, that issue appears to have gone away. I'm still not seeing anything in the recent list. That's a minor annoyance, but since a few of you have told me that it works for you, I'm quite puzzled by that one. I wouldn't think there would be a setting related to that, but I'm coming around to the view that Niya stated, which is that there is a setting for EVERYTHING in VS, so...is there a setting related to showing recent dlls, projects, or files?

One thing I discovered is that there IS a setting that gets the release builds working the same way as the debug builds as far as debugging, it's Suppress JIT Optimization On Module Load." This will allow the stepping through dlls whether in release build or debug build, so while I did get the debug build to actually...well...build, with the reinstall, now I realize I didn't actually NEED to.

If you believe you're found an issue with VS2019, then raise it as a problem with MS. From VS, Help/Send Feedback/Report A Problem.

Shaggy can I ask why your dynamically loading dll's? what advantage are you getting from this?

The way I have always worked is to add any projects I use into the main solution and so I can debug all the code directly and when I build the solution it rebuilds all the necessary dll's that go with it.

If you're using any type of source control then I wouldn't work any other way.

As for debug builds not working properly the only time I have seen this issue is when the settings for the debug builds are not correct on the configuration manager.

I have seen projects where the debug build is actually outputting to the release folder and the only way to fix that has been to delete the debug build option and recreate it setting the folder to the correct place.

The dlls are loaded dynamically because they are plugins. The set of plugins can change at any time, and, of course, are added after program installation, so dynamic loading is the only option.

The strange debug behavior came down to that one setting and nothing more. One of the things about VS versions after 2010 is that more and more options have been added. New features have also been added, to be sure, but lots of things that were always available are now more flexible, and have options. For example, break behavior and exceptions used to be a fairly simple thing in 2010. You could essentially have it or not. In later versions of VS, this was broken into a widely nuanced set of options such that you can customize debug behavior in this area to a very fine scale.

In some cases, I don't see the point, but then again, I'm not supposed to. The point behind options is to give the ability to them what needs 'em. If you don't need them, then you don't have to use them. In this case, I kind of think the default wasn't well chosen, but it's just a checkbox.