¶Can I have my VC6 project build back, please?
You might have noticed at this point that I spend a lot of time blogging about issues with Visual Studio. The reason is that I spend a lot of time using it -- both in a professional and hobby capacity. When it works well, I work well, and when it doesn't... well, I'm told that I swear a lot and that a Microsoft Natural Keyboard Pro is not meant to be used with a fist. I broke a plastic keyboard tray in college that way.
For the most part, I'm fairly pleased with Visual Studio 2005. However, there is one major area that still causes me problems, and that is the build system -- specifically, that it doesn't work like Visual C++ 6.0's. It's a lot better than the one from Visual Studio .NET, but still has the following flaws, IMO:
- It builds all of the active projects in the solution, not just the startup project. There's a "build only startup project on run" option, but no "build only startup project on build" option. Creating new sets of solution configurations for each startup project seems needlessly redundant.
- It doesn't stop when a build error occurs, so it takes longer to run through unless I happen to see the error scrolling by, and then there's lots of spew from failed dependent projects that had no chance of succeeding.
- It sometimes continues linking dependent projects over and over until I wipe the exes/libs and force a clean relink. Seems to be a file timestamp problem somewhere... I thought it was just the .manifest files, which is a known problem, but I disabled those, and it seems the .pdbs are sometimes affected too. In my case, this causes one of the tool .exes to rebuild... which then causes another project to recompile its .fx files using that tool, and then recompile and relink the resultant data arrays... which then causes that static lib to be relinked into the main executable... aaahhhh!
That blog entry I wrote on Visual Basic's Dim command? Well, that arose out of me trying to write a VBA macro for VS2005 to fix the first problem. It's been suggested that SolutionBuild.BuildProject() with the active configuration will accomplish "build startup project," but it fails miserably if you have both x86 and x64 configurations -- seems that both configurations get the same name and BuildProject() can't distinguish them. Argh. It looks like to fix either the first or the second problems properly I'll need to write an Add-In, which I'm reluctant to do because (a) this should be built-in, and (b) I still have bad memories from when I tried to fix FastSolutionBuild, which crashes if you have C# projects in a solution. And I have no idea how to fix the third.
Oh well. It's still a lot better than when I was making makefiles by hand for use with Lattice C++ or Watcom C... really sucked when I got the .h dependencies wrong and files didn't build when they should have.