Visual Studio 2013 Intellisense Not Updating When Header File Changed in Other Project

Question

I'm having a frustrating problem with C++ Intellisense in Visual Studio 2013. (If you're dealing with other versions of VS, please don't answer. Intellisense has changed dramatically over the versions, and my experience is that answers for one VS version aren't usually helpful for later versions.)

I frequently work in multiple projects with multiple instances of Visual Studio. When I make a change in a header file in a library, for example, Intellisense should detect the changed file and update the application project I also have open. This used to work, and I believe it stopped working when I installed an SSD. The behavior seems to indicate that VS simply doesn't detect when a file is changed on the disk outside of the current project.

I don't see how moving to an SSD would change that detection, but that's the best guess I have. I've experimented and searched for an answer without any luck, so any guidance would be helpful.

Thank you, Doug

Answer 1

The C++ IntelliSense never really tracked file modifications across Visual Studio instances. I believe your prior observations must have been an illusion or biased.

For example, one scenario where it might have "kind of" worked is: in instance A of Visual Studio you had header.h opened and applying modifications to, in instance B of Visual Studio you had header.h and source.cpp(using the header) opened. The opened header.h in instance B would be "noticing" the changes (there might be a dialog box asking for reloading the file, or the option to reload automatically might be set) and notifying the source.cpp IntelliSense to be reloaded. IntelliSense will also refresh the whole file periodically or in response to some user edits, so this might have been another explanation; although less deterministic, and of course should not be impacted by changing the hard drive.

In general, working on the same files across multiple Visual Studio instances is (as you can see) not well supported scenario. I would suggest an alternative approach to group your multiple projects into a single solution and work in a single instance. On a practical side, note that you might configure your own "workspace" solution which is referencing the select projects you need without impacting the team's solution files -- I do this quite frequently as I'm usually interested in only 2-3 projects out of N my team works on.