next »

[TheLastBanana]

Visual Studio is driving me nuts.

When I build and run my project in debug mode, it sometimes runs old code for reasons I can't discern. My latest change won't have any effect, and if I encounter any breakpoints, VS complains that the compiled version and the source code don't match up.

Strangely, it seems like the executable itself is being updated, as are the relevant .obj files, or at least their timestamps suggest as much. The only way to solve the problem is to either delete main.obj and let it rebuild, or to delete vc120.idb (the "Minimum Rebuild Dependency File").

I have a feeling this is related to the minimum rebuild system, because it seems like Visual Studio is making some invalid assumptions about what does or doesn't need to be updated... but for the life of me, I can't figure out how to solve the problem.

[Garthy]

Visual Studio is driving me nuts.

When I build and run my project in debug mode, it sometimes runs old code for reasons I can't discern...

A few ideas:

- Are the timestamps and the system time sane, ie. is your system clock typically correct when you first boot up the PC? If you manually look at the modification times on the source and object files do they have sensible modification times? Are there any future-dated files?

- Does the problem occur with files that you saved during the current build pass, ie. you start a build, save a file, and the build finishes later?

- Something possibly worth experimenting with may be the settings for pre-compiled headers, incremental linking, edit-and-continue, and minimal rebuild. Basically, disable these, do a full clean build, and stick with these settings for a while. If the problem stops you have a lead and test them individually. If it occurs again then this isn't it.

- If you modify a source file and then fire up a debug instance directly (without specifically building), does it build the file, offer you a choice, or just launch the app?

[TheLastBanana]

- Are the timestamps and the system time sane, ie. is your system clock typically correct when you first boot up the PC? If you manually look at the modification times on the source and object files do they have sensible modification times? Are there any future-dated files?

No clock wackiness as far as I'm aware. Everything is sane and matching up with the actual times that I ran builds.

- Does the problem occur with files that you saved during the current build pass, ie. you start a build, save a file, and the build finishes later?

Nope, I'm always starting the build after saving the file.

- Something possibly worth experimenting with may be the settings for pre-compiled headers, incremental linking, edit-and-continue, and minimal rebuild. Basically, disable these, do a full clean build, and stick with these settings for a while. If the problem stops you have a lead and test them individually. If it occurs again then this isn't it.

I'm not using any pre-compiled headers, though I may try messing around with the options anyway.

I tried disabling minimal rebuild and doing a clean rebuild, but the problem persists. Same deal with incremental linking and edit-and-continue.

- If you modify a source file and then fire up a debug instance directly (without specifically building), does it build the file, offer you a choice, or just launch the app?

I have it set to always build when running a debug instance. The build output lists the file, which suggests that it is in fact being built.

[Garthy]

Hm, they'd be the main ones I know about.

Definitely try disabling the precompiled headers option as Visual Studio used to (about a decade ago anyway) stuff up the build with certain changes to header files, particularly those that enable blocks of code in other files.

The only other things I can think of off the top of my head are a bit unlikely, but here goes:

- There can be issues building from or to a network share, particularly those provided by a virtual machine.

- I also seem to recall something about build problems relating to the granularity of timestamps, where a build within a couple of seconds of the save could cause the object file to *not* be rebuilt, but I think this was only on FAT filesystems, and not NTFS. Perhaps though if the build was being run from a USB stick? I'm guessing you're probably not doing that though?

[oahda]

I always just do a clean build when stuff like that happens and it tends to work out. It's the restarting the computer of programming.

Is that too simple to be a solution in this case?

[TheLastBanana]

No network or USB builds here either, so I don't think those are the problem. When I'm bit more awake tomorrow I'll try poking around at the precompiled header options.

@Prinsessa: I have indeed tried doing a clean build, restarting Visual Studio, restarting the computer, and even making a fresh clone of the project repo... no dice.

[InfiniteStateMachine]

What type of VS project is it? Also which compiler/build system are you using?

[TheLastBanana]

I'm using VS Community 2013 with compiler version 120. The project compiles to an executable, and it's using the standard VS system for local builds -- I'm not using a build server or anything if that's what your asking.

EDIT:
I've noticed that it's only happening with changers in header files -- changes in cpp files are being reflected. The mystery deepens...

[InfiniteStateMachine]

Oh I was more asking if you were using clang/gcc with make/jam etc.

I cant think of any time something like that has happened to me in VS. I've had it happen once or twice when using a different compiler/build system or if I did enough to mess up incremental linking.

Every once in a while I hit spacebar in a file during a build and save by accident, that causes debug breakpoints to go invalid.

I'm using VS Community 2013 with compiler version 120. The project compiles to an executable, and it's using the standard VS system for local builds -- I'm not using a build server or anything if that's what your asking.

EDIT:
I've noticed that it's only happening with changers in header files -- changes in cpp files are being reflected. The mystery deepens...

What kind of changes are you making?  I may have to try changing some headers today and see if that does the same thing for me too.

[Sik]

This reminds me of a problem I used to have with... Dev-C++, out of all things. (bad configuration made it unable to detect changes in headers properly, i.e. if a header changed it wouldn't rebuild the files depending on it unless they were explicitly modified too) Go figure.

[JWki]

I've had the same problem before, changes in header files wouldn't be reflected in the build results, I noticed it because I had a lot of configuration variables in header files and changing configurations wouldn't do anything. I could fix that with turning off minimal rebuilds though, and now that's one of the first things I do when creating a new VS project.

[Sqorgar]

I've had the same problem before, changes in header files wouldn't be reflected in the build results, I noticed it because I had a lot of configuration variables in header files and changing configurations wouldn't do anything. I could fix that with turning off minimal rebuilds though, and now that's one of the first things I do when creating a new VS project.

I haven't used Visual anything in a decade, but if I had to guess, I'd say that precompiled headers are the problem. The headers are compiled separately from the code, so when the headers change in a way which does not change the public interface, it doesn't recompile the files that depend on it. Since #defines are preprocessor, VS may not track dependencies - though that would totally screw up stuff like #ifdef. Don't know. Always considered Visual anything to be crap.

Also, I wouldn't put configuration data in a header file, because changing something like a port number could result in recompiling the entire project. A better approach is to use const global variables, which are referenced from a header file. That way, you can change the values all you want and you only need to recompile a single file.

[TheLastBanana]

What kind of changes are you making?  I may have to try changing some headers today and see if that does the same thing for me too.

The header just contains a class derived from another class, with a handful of small function declarations and definitions. Nothing I change has an effect, including changes in function code, class members, or the class' public interface.

EDIT: I gave up trying to track down the problem and just recreated the project from scratch, adding back all the source files and manually reconfiguring the project settings. Now everything is hunk-dory.

[InfiniteStateMachine]

I've had the same problem before, changes in header files wouldn't be reflected in the build results, I noticed it because I had a lot of configuration variables in header files and changing configurations wouldn't do anything. I could fix that with turning off minimal rebuilds though, and now that's one of the first things I do when creating a new VS project.

I haven't used Visual anything in a decade, but if I had to guess, I'd say that precompiled headers are the problem. The headers are compiled separately from the code, so when the headers change in a way which does not change the public interface, it doesn't recompile the files that depend on it. Since #defines are preprocessor, VS may not track dependencies - though that would totally screw up stuff like #ifdef. Don't know. Always considered Visual anything to be crap.

Also, I wouldn't put configuration data in a header file, because changing something like a port number could result in recompiling the entire project. A better approach is to use const global variables, which are referenced from a header file. That way, you can change the values all you want and you only need to recompile a single file.

Oh yeah I forgot about that. I never use PCH that comes built with an IDE or platform. If I do it's in a system designed inhouse and has very explicit rules.

[JWki]

I've had the same problem before, changes in header files wouldn't be reflected in the build results, I noticed it because I had a lot of configuration variables in header files and changing configurations wouldn't do anything. I could fix that with turning off minimal rebuilds though, and now that's one of the first things I do when creating a new VS project.

I haven't used Visual anything in a decade, but if I had to guess, I'd say that precompiled headers are the problem. The headers are compiled separately from the code, so when the headers change in a way which does not change the public interface, it doesn't recompile the files that depend on it. Since #defines are preprocessor, VS may not track dependencies - though that would totally screw up stuff like #ifdef. Don't know. Always considered Visual anything to be crap.

Also, I wouldn't put configuration data in a header file, because changing something like a port number could result in recompiling the entire project. A better approach is to use const global variables, which are referenced from a header file. That way, you can change the values all you want and you only need to recompile a single file.

I would have suspected that too, if I'd use pch, which I don't.
Good point about the globals, I now rely on more data driven approaches though.

[bengrue]

Seriously, I've been using Visual Studio for like 20 years at this point.

Where's the smart file open?  CTRL-P in Sublime?  CTRL-SHIFT-O in all of the Jetbrains IDEs.

Am I just googling for this shortcut wrong?

Fuuuuuuuuuuuuuu

[InfiniteStateMachine]

I'm guessing smart file open is where you type something in and it does a fuzzy search? If so I'm not aware if VS has that. They have the search solution field but it's not that great.

ctrl-shift-o does work if you have vissual assist x though. It's 100$ but well worth it.


EDIT : A quick google returned this http://stackoverflow.com/questions/1003445/key-shortcut-in-visual-studio-to-open-a-file-inside-your-solution

[Layl]

Seriously, I've been using Visual Studio for like 20 years at this point.

Where's the smart file open?  CTRL-P in Sublime?  CTRL-SHIFT-O in all of the Jetbrains IDEs.

Am I just googling for this shortcut wrong?

Fuuuuuuuuuuuuuu

Try ctrl-t in ReSharper (if you have it), it's basically everything you like in IntelliJ for Visual Studio.

[InfiniteStateMachine]

Isn't reharper only for C#? I suppose he could be using the language but he didn't specify.

[Layl]

Isn't reharper only for C#? I suppose he could be using the language but he didn't specify.

ReSharper also has a C++ version. If you're using F# however you're Fed