Why does VisualStudio not "react" to errors sometimes?!
Hi,
on several occasions now I had worked on a project for a long time, and every code update recompiled fine. Then suddenly, a new recompilation threw errors at places where I haven't changed anything for ~15mins or longer. It should have caught those errors the first time compilating and prevented me from starting the application, right?
I assumed that this happened because I had started with strg+f5, which starts without debugging and uses the already existing debug .exe. (right?)
I'm not so sure anymore, because a fellow student swears that she always started with f5, and still ran into the same problem. Does Visual Studio optimize the creation of .exe? This is a major problem! The first time I had to look for a memory leak for ~2 hours, because I had made so many changes in between compilations.
Do you have an explanation for this?
edit: visual studio 2008 btw.
[Edited by - Meai on November 9, 2009 2:09:21 AM]
You're saying you've made code changes and some files haven't been recompiled? I've never seen issues like this with VS.
Are you talking about compile-time or runtime errors?
If compile-time, are you sure you didn't make an error in a header file, causing VC to report an error in seemingly unrelated code that ends up #including the actual file with the error? Compile errors aren't perfect.
If runtime, maybe you happened to expose some latent bug (undefined behavior?) that's always been there but never looked like it was causing problems before. Some bugs cause the program to crash and halt immediately - you're lucky in these cases. The worse bugs are those that don't crash but silently corrupt data, possibly crashing much later in the code or simply causing unexplainable results.
Are you talking about compile-time or runtime errors?
If compile-time, are you sure you didn't make an error in a header file, causing VC to report an error in seemingly unrelated code that ends up #including the actual file with the error? Compile errors aren't perfect.
If runtime, maybe you happened to expose some latent bug (undefined behavior?) that's always been there but never looked like it was causing problems before. Some bugs cause the program to crash and halt immediately - you're lucky in these cases. The worse bugs are those that don't crash but silently corrupt data, possibly crashing much later in the code or simply causing unexplainable results.
Ah I think I know what the problem is (rather silly): I always assumed that f5 always recompiles (which it does often, but apparently not always).
I should start pressing ctrl+f7.
Thanks for your input.
I should start pressing ctrl+f7.
Thanks for your input.
F5 should ask to rebuild any changed files (at least, it does by default).
Are you sure you didn't check the "Do not show this dialog again" option in the prompt dialog?
You can check and possibly re-enable it in MSVS's options dialog:
Are you sure you didn't check the "Do not show this dialog again" option in the prompt dialog?
You can check and possibly re-enable it in MSVS's options dialog:
Quote:On Run, when projects are out of date
If a project configuration is out of date when you press F5 or choose the Start command from the Debug menu, a message is displayed. You can choose whether to build the project and whether the message is displayed each time that a project configuration is out of date. Use this option to specify whether the message is displayed and the default build behavior if it is not.
I have noticed that in older versions of VS (older than VS 2008, dunno if they have fixed it) the incremental builder will not always detect changes in *header* files, especially if they are not included directly in any compilation units. As in: A.h is included in B.h which is included in B.cpp. Changes in A.h will not always trigger a build. Can be quite annoying.
I've had this problem (read: changed files not triggering recompilation) in pretty much every single build environment I've worked with, though obviously the variance has been high with this problem occurring more frequently in some environments than in others.
As long as it occurs extremely rarely it's not something that particularly bothers me.
As long as it occurs extremely rarely it's not something that particularly bothers me.
I checked the Options->Projects and Solutions->Build and Run
and I have enabled: "on run, when out of date, always build"
BUT: The issue seems to lie on the definition of "up to date". I changed the option back to "prompt dialog every time on run and when project is out of date"...and F5 doesn't prompt me with a dialogue, and starts an old debug .exe.
Only fix is still ctrl+F7.
edit: there are no header files in the test project that currently shows these problems.
edit:
It will bother you, once you get memory leaks and can't find them because the compiler warned you later/too late.
and I have enabled: "on run, when out of date, always build"
BUT: The issue seems to lie on the definition of "up to date". I changed the option back to "prompt dialog every time on run and when project is out of date"...and F5 doesn't prompt me with a dialogue, and starts an old debug .exe.
Only fix is still ctrl+F7.
edit: there are no header files in the test project that currently shows these problems.
edit:
Quote:
As long as it occurs extremely rarely it's not something that particularly bothers me.
It will bother you, once you get memory leaks and can't find them because the compiler warned you later/too late.
I am relying on Visual Studio to detect changes in a rather large workspace: ~10 projects, ~15 minutes for a complete rebuild, with public header files in a special directory and internal header files together with the source files and cross-project includes.
In the past 18 months, I can't remember a single instance where Visual Studio has let me down.
Are you maybe using the same output directory for debug & release builds? Two projects outputting into the same directory perhaps? Often doing VCS reverts? Maybe store your projects on a network share or other non-local file system?
In the past 18 months, I can't remember a single instance where Visual Studio has let me down.
Are you maybe using the same output directory for debug & release builds? Two projects outputting into the same directory perhaps? Often doing VCS reverts? Maybe store your projects on a network share or other non-local file system?
Last time I had VS failing to notice files had changed it was because some of the file modification dates were (somehow) in the future. I'd check your computer's date and (if possible) run a recursive touch over all of your project files to bring them up to date.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement