Visual Studio 2010 is here

Late to the party, I know. Considering that VS2010 has been in open beta for a long time and it also has been out for a while I'm really late. In the vein of not trying to blaze any paths and let everyone else die on the landmines that Microsoft usually plants for new releases of Visual Studio I've been intentionally hanging back. I've been clinging to VS2005 for a very long time, as it seems that it was the one version that has been working decently for a very long time. Visual Studio 2008 really didn't hold any interest for me, indeed it seemed mostly a maintenance release for C# and .NET while providing nothing new for us lowly C++ programmers.

VS2010 however seems to finally have overhauled and replaced the old C++ build system in favor for the much touted MS Build system as well as starting to support C++ 0x (static_assert ftw) which all the sudden makes it interesting. The thing that pushed me over though was the fact that apparently the most recent DirectX SDK doesn't support 2005 anymore! The mind boggles a little about that one. So in fact, it seems that with a couple of hotpatches and if you manually go in and patch the header sal.h [1] you can kind of make it to work, but I quickly realized that you're fighting an uphill battle. Naked. With paper machè swords. Against a Nazgul. Time for a tactical retreat.

Taking the plunge

Throw out the old, in with the new. Starting up the editor and ... wait. I have nothing. No project files, no plugins and no know-how. I'm such a noob. Again. Time to hit the interwebs for some research on how these things actually work. A little later I come out armed with some knowledge and I'm ready to start porting my plugins: NiftyPerforce and NiftySolution. Without them I simply cannot work. So first order of business. Add the following to the .AddIn xml file:

... wait, that was it? What the heck was I sweating about? Heck, that was easy. Makes me wonder a little bit what all the fuss was about? Anyhow...

Build files

Next order of business. I needed to convert all my projects at home to VS2010 format. Of course it's a new format, but looking closer at them it turns out that they've done something quite smart.

• The build files are regular msbuild files.
• The UI element control stuff is moved out to a separate file, .vcxproj.filters
• While the UI generates pretty horrible files, it agrees to parse seemingly any valid msbuild file, which allows us to generate decent ones and use them.

So I sit down and port badgerconfig in a day to the new format and I am quickly up and running with the entire homegrown codebase that I have. Next really pleasant surprise I get is that with the new buildsystem finally parallel builds work. Not only project, but individual .cpp files can now be translated in parallel [2]. Without the annoying dependency cluster fuck that happened in previous versions.

Speaking about dependencies. I ran into two issues while exploring the build system. First was that apparently if you have a reference to a header that doesn't exist on the filesystem, the project that lists that header will insist on doing a build step every time. At first I went sigh, the system is still broken. My colleague Cedric informed me though that it most probably was a header that was missing. Lo and behold, I finally tracked down the offending header. So watch out for this if you have constantly building projects even if you just built them [3].

Second really gnarly issue also had to do with constantly building projects, but this one was more random. I noticed that sometimes, projects still had a build step even though I just built them, sometimes even triggering rebuilding of actual .cpp files! Most notably and annoying was when I just pressed build (F7) and directly after that pressed debug (F5). You would expect that I would be rewarded for waiting all that time for the code to compile by an instant response and being dumped into the debugger? Oh, no. Please wait while I compile these files. Again. So it turns out that MS Build is smart. Very smart. It actually tracks dependencies automatically by hooking into the filesystem and checks the files that were touched by the processes it launches, including the debugger. But today, just because you launched a process, it might not be responsible for all the files touched. I found out that we have a corporate client management system that tracks all the activity happening on our computers at work, including what the compiler does. Tracking is done by writing down a temporary log file. Yes, it will be tracked by MS Build. And sometimes that timestamp was more recent than the product coming out of the compiler and the resulting recompile caused me to curse like a sailor.

Another really annoying fact was that while the custom build steps in the old Visual Studio happily accepted command files (.cmd or .bat) happily, the new Visual Studio seems to do collect the custom build steps behind the scenes into a master batch file, like this:

The observant reader have already spotted that this could never work. Indeed, only the first command is ever run. This will exhibit itself if you have several custom rules in one project, each of them calling a batch file to transform the data. You then have to press F7 an equal amount of times as you have custom rules to fully compile the project.

(silent minute of cursing)

Of course, calling a batch file from another batch file terminates the calling batchfile. So you have to call the batchfile through cmd /c instead. In your custom rule. So beware if you are just upgrading old .vcproj files blindly. This one took a while for me to figure out.

In closing...

While having ported some of my software over and worked out the kinks I had in the setup of the build system, I found myself in a very happy place. Compilation is now using all of my cores most of the time and build times have gone down significantly. It seems that the new build system is much more reliable than the old one in terms of dependencies so I'm starting to trust it more.

The UI itself has several nice improvements (hey docking seems to work finally) and intellisense at least seems better (doesn't break as often). I guess we had a good 5 years run with 2005 and I managed to avoid the pain of upgrading to 2008 so I guess the times are finally upon us to put Visual Studio 2005 behind us. I will remember it with fond memories of all the code I wrote with it. Here is for another 5 years with the same IDE!

Footnotes

Comments