[RESOLVED] VS 2019 Has Gone Nuts

I have a project that I have worked on for several years. It references a dll that is in a different project. Today, I got an odd error message, and when attempting to debug it, decided that part of the problem was that I was targeting the release version of that dll, which prevented me from seeing something that seemed likely to matter.

That's a simple problem, so I switched to the debug build of the dll. That resulted in a few other errors about an interface having the wrong signature for a method. That was a change I made years back. It was as if the project had reverted partly to some older version that was no longer in use...or even in existence.

That was really weird. Rebuilding did nothing, cleaning did nothing, so I went and deleted the bin and obj files and rebuilt...it simply won't. I've tried it a couple times. Either the bin and obj folders are not created, or they are created but only either release or debug folders are created under there (I'm only building the debug version, so why is only the release folder being created...but only sometimes), and the folders are empty when they are there.

So, it's giving no errors, the icon imagery suggests that it really is building the thing, but it isn't creating any output, including not always producing the folders that it should...though sometimes it creates them and sometimes they are empty.

Any suggestions?

And then it all fixed itself. That was frustrating.

The reason it wasn't building turned out to be be that something got changed in the Configuration Manager such that Rebuild All did not build anything. Considering that I never go into the Configuration Manager, it's a bit hard to see how that managed to get changed, but it could be as little as a bit getting flipped, which could happen by a variety of unhappy accidents.

Why the folders weren't being created, though only sometimes...well, I can't say that I understand that one. Perhaps that has something to do with Configuration Manager, as well.

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.