The productivity sink

Visual Studio is a very productive development environment. However, you can get Visual Studio into a state (for C++ and C developers, at least) where the compile and link both succeed, but when you go to run the executable Visual Studio annoyingly tells you that the build is out of date and would you like to build it?

This is a very frustrating experience. You go around and around in circles trying to work out what is wrong with the project that is causing this warning message to be displayed.

After some head scratching you’ll Google it and find solutions on numerous websites that tell you to do this, or that, or the other. The advice on some sites is consistent with the advice on other sites, some advice is not consistent. Then you find that some advice is for one version of Visual Studio, but you need to do something differently for a different version of Visual Studio.

It’s a mess. But you work out what you need to do, set about it and after tweaking a registry setting, running a tool to grab the output from OutputDebugString (or writing one if you couldn’t find a tool!), you now know which file is causing Visual Studio to tell you the build is out of date. Great!

Er, not so fast. The problem with this is Visual Studio only tells you about the first file that causes it to need to be rebuilt. Any other files aren’t listed, so you have to make the change then repeat the whole cycle. Slow!

“Crikey, that was a lot of effort, I hope that doesn’t happen again”, you think, or perhaps something a bit less polite. And then you remember you’ve got 10 more projects that behave like this, but you’d been ignoring that for a long time. But now you know how to fix it, but you can’t imagine putting in the effort for those 10 projects.

That was the situation we were in, except that just about every project we had (over 200 projects) had this problem. After tackling just one project I knew we had a choice:

• Ignore the warnings.
• Fix the warnings manually. Very slow. Lots of typing. Boring. Morale killer.
• Find a way to automate the fixing of these problems.

Our engineering needs drove the decision.

Visual Studio Project Fixer

We decided to write a tool to make the hard bits of the above easy and to automatically discover what was wrong with a project file, then allow the user to choose which items to fix and which to leave alone. Plus an automatic mode that just fixes everything for you.

Things that can affect a project file are:

• Missing files. The file exists on disk, but is not specified in the project.
• Incorrect files. The file exists on disk, but not in the location specified in the project
• Nonexistent files. The file doesn’t exist on disk, but is specified in the project.
• Obsolete files. Files from older versions of Visual Studio.
• .tlog files. Visual Studio file dependency files.

Some examples…

Missing file. You have a class defined in class.h and implemented in class.cpp. Only class.cpp is listed in the project file.

Incorrect file. A file is listed in the project as ..\svlCommonUI\class.h but is actually located at ..\svlCommon\class.h.

Nonexistent file. A resource file is specified that doesn’t exist. .\images\nonexistent.bmp.

Obsolete file. An old format help file from an early version of Visual Studio, carried over in Visual Studio project conversion.

A simple user interface

The image above shows the user interface after a scan of many projects has been performed. The summary display is shown, which lists an overview of the state of the projects and provides an option to automatically fix all the projects. If you click an individual project, the display changes to provided detailed information about that project.

There are four ways of scanning projects, providing for maximum flexibility in automating fixes or manually choosing each fix to apply.

• Open a project.
• Open a solution.
• Open all projects in a directory (and sub-directories).
• Open all projects in solutions in a directory (and sub-directories).

Having scanned some projects you can examine the results and choose to fix individual projects, or to fix all the projects that need fixing.

The default settings are to backup all project files before modifying them.

Diagnostic Information

It is possible that even with all the information provided by Visual Studio Project Fixer you may still wish to view the output from Visual Studio. Visual Studio 2015 and 2017 provide an option to show you this information. However for Visual Studio 2010, 2012 and 2013 you can enable diagnostic information to be sent via OutputDebugString(). This means that Visual Studio Project Fixer can intercept this information. All you need to do is enable it (from the Edit menu).

Then every time Visual Studio checks the status of a build, it’s output can be seen on the Visual Studio OutputDebugString tab.

Fix your Visual Studio Projects

We’ve been using Visual Studio Project Fixer in house for some time. We thought it was about time everyone else got a chance to use it. We’re making this available for free. Learn more about Visual Studio Project Fixer.