Visual Studio 2019 sometimes won't compile/link in new changes, resulting in inactive breakpoints?

Carl Colijn 96

I'm using Visual Studio 2019 Professional (version 16.7.7+30621.155), and when I'm compiling a big C++ DLL project (incl. our own static libs) the compiler and/or linker sometimes refuses to take in minor updates to the code.

Scenario:

I stop a debug session and alter a line here and there in the static lib part of the code,
I press F7 to recompile, and I see the static lib gets recompiled and the final DLL gets relinked,
I press F5 to run the host app which loads my DLL in turn,
The existing breakpoints in the file I just changed are now non-functional, saying that "The source code is different from the original version".

It doesn't happen every time, but enough times to really start to annoy me. A remedy is to clean and/or rebuild all, but in my case that is a lengthy process which I'd rather not do too often. I already once checked the timestamps of both the altered source file and the corresponding cached object file, and the object file did get updated...? Just now I also encountered this issue again, and I decided to "Project only \ Rebuild", and while it did rebuild the static lib the breakpoint is still inactive with the same message...? The object file's timestamp is a few minutes newer than the cpp file's timestamp, so I assume my changes got compiled in?

I also sometimes used to have this issue now and then under VS 2017 (using the 2015 toolchain), but one day the problem went away and I never saw it again. Until I now upgraded to VS 2019.

What could be the problem here?

ps: after writing this post I added+removed a space to the cpp file in question, pressed F5, the file got recompiled and the project re-linked, and now the (unaltered) breakpoints work again. It almost seems as if the compiler and/or linker use a minutes-only time resolution when comparing file time stamps, but that can't be true, right?

David Lowndes 4,711 Reputation points

2020-11-11T15:49:46.717+00:00

I'd guess that something's keeping your DLL loaded so that even though it's rebuilt, whatever process you're debugging still has the prior version.
Are you debugging an Explorer shell extension extension?
Carl Colijn 96 Reputation points

2020-11-11T16:06:44.637+00:00

No, not at all. The host app is just a regular .exe that I set as the executable to run in the project's debug settings. And the host is definitely down when I recompile; I just shift-F5-ed it out of it's misery before making the code change :) When it happens again I'll also check the resulting DLL file timestamp, just to be sure.
David Lowndes 4,711 Reputation points

2020-11-11T16:31:08.677+00:00

You could also use Process Explorer to make sure nothing else has a handle open to the DLL too.
Carl Colijn 96 Reputation points

2020-11-11T16:56:33.337+00:00

It just happened again, and the object file is a few seconds newer than the source file, but the dll is... older than both? So it seems everything is compiled in order, but the linker sometimes fails to update the resulting binary? The incremental link file next to the dll had the same time stamp as the dll itself.

Removing the dll file and pressing F7 made VS update both the dll and the ilk file, and that fixed the code/dll mismatch.
Carl Colijn 96 Reputation points

2020-11-11T16:56:43.597+00:00

Interesting side note: my project consists of a shared static lib and quite a lot of individual DLL projects (each taking in the shared lib). When I removed the DLL file above I also checked the other DLL file's time stamps, and they were all not updated, incl. their ilk files. When I removed just one DLL, all other DLLs and ilk files got updated, so not only the DLL I test-deleted. Then again there was some time between the initial code change + compile, and the later removal of the DLL and the rebuild, so waiting a few minutes and just recompiling might just also have been the trigger.
Carl Colijn 96 Reputation points

2020-11-11T16:58:07.153+00:00

Wanted to post this as one reply, but apparently this new forum only allows a mere 1000 characters per reply???
Carl Colijn 96 Reputation points

2020-11-11T16:59:00.657+00:00

Then again: if another process has the DLL open and/or locked for write, wouldn't that lead to a linker error?
David Lowndes 4,711 Reputation points

2020-11-11T17:02:04.557+00:00

Any sign that the linker ran in that situation? Any error in the output pane?
Carl Colijn 96 Reputation points

2020-11-11T17:29:26.02+00:00

No errors whatsoever.

But I've found the cause. I usually press F5 for recompile/relink/debugging, and while that did trigger a recompile+relink, the actual DLL files again didn't get updated; their timestamp was 4 minutes older than 'now'. When I immediately killed the host process (shift-F5) and started it again (F5), nothing happened (no recompile/relink) before the host got started up. I then stopped the host again (shift-F5), directly pressed F7 afterwards, and the projects got relinked again and the DLLs did get updated. Doing an F5 rebuild with output verbosity cranked up a bit I saw no linking happened at all.

Checking the settings, I had "Only build startup projects and dependencies on Run" checked. And I usually have the static lib itself as the startup project (so I don't have to copy modified debug settings to all 80+ other DLL projects). So unchecking that option fixed it.
Carl Colijn 96 Reputation points

2020-11-11T17:29:46.36+00:00

This surely was the reason; many thanks for your time and other suggestions though!
Carl Colijn 96 Reputation points

2020-11-11T17:31:45.917+00:00

ps: the above line was meant as the closing line of the reply above it, and while the editor said I still had 9/1000 chars left, it just wouldn't submit (the button wasn't greyed out though). Removing the line made the submit work again, so I think the javascript validation is checking against something slightly smaller than 1000? Maybe it's worthwhile to report this?

Accepted answer

Carl Colijn 96 Reputation points

2020-11-11T17:39:07.5+00:00

There apparently is a VS option named "Only build startup projects and dependencies on Run", and if your workflow consists of just pressing F5 to win, having this option accidentally unchecked will make your life miserable. Or rather frustrating and confusing that is, when you do sometimes sprinkle in an F7 so that "sometimes it works, sometimes it doesn't".

Thanks @David Lowndes for your other suggestions and putting up with me anyway :)
Please sign in to rate this answer.

0 comments No comments
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.

Share via

Visual Studio 2019 sometimes won't compile/link in new changes, resulting in inactive breakpoints?

0 additional answers

Your answer