Finding errors / warnings in Visual Studio

Question

I have experienced an annoying issue with Visual Studio 2005... sometimes when I rebuild, and even if I do a Rebuild Solution, it will come back with no errors or warnings, but then when I later edit another code file, even without changing it, and rebuild, it will find an error or warning in that other file. Clearly, the earlier Rebuild Solution did not recompile that file! How can I force VS to completely recompile every file?

Answer 1

Is this related to the Configuration Manager? There you can select which projects in your solution build. Not sure if this helps.

Answer 2

It might help to clean the solution prior to rebuilding -- right click on the solution in the Solution Explorer and choose "clean solution" -- this deletes temporary files and is supposed to clear out the bin and obj folders, so everything is rebuilt.

Answer 3

Depending on the types of warnings it is not possible if I recall correctly.

For example, warning messages for XHTML compliance are ONLY displayed when the file is open. You might check the tolerance settings inside VS to see if you can change it.

Answer 4

I'm with Guy Starbuck here, but would add that Rebuild Solution is supposed to do a Clean Solution followed by Build Solution, which should, then, have solved your issue to begin with. But VS 2005 can be terrible in this regard. Sometimes it just starts working after several rebuilds. If upgrading to 2008 isn't an option, consider manually clearing the bin folder.

Answer 5

This sounds strange - Rebuild should build everything regardless of changes and Build should only build things that have changed.

The behaviour you've described should only happen if you have modified something that is referenced by the unchanged file so that it is now incorrect.

Answer 6

I've seen this happen before when you have multiple projects in your solution and the references get mixed up.

Say you have four projects in your solution, Common, Business, Data, and UI. Assume that Common is referenced by the other three projects.

What we want is for Common to be a "project reference" from the other three projects - they'll then pick up their copy from the build output directory of Common.

But, sometimes, one of the projects will get it's reference mixed up. Say, in this case, that UI starts referencing the copy of Common in the build output directory of Data. Now, any change that compiles "UI" without also compiling "Data" will result in two, possibly incompatible, versions of "Common" being a dependency of UI.

Another scenario is where the reference is to a binary, such as from a "lib" directory. Then, one of the projects ends up referring to a build output location instead of lib.

I don't know what causes this - but I see it all the time, unfortunately.

The fix is to go through the references of each project and find the one (or more) that point to the wrong place.