I have more or less completed the task of migrating my internal projects to Visual Studio 2010. Native C++ programmers are pretty low on the totem pole of programming coolness these days, but Microsoft did throw us a few bones. At this point I have to say I’m ambivalent overall with VS 2010, but I really like some of the architectural changes and I’m excited about the future.
The Good
The new intellisense database is a huge improvement over the old .ncb file. I’ve had a few hiccups, but in general nothing serious. It still locks up the IDE occasionally, but not nearly as often or as long as previous versions. In previous versions I had to delete corrupted .ncb files all the time; those days appear to be gone in VS 2010.
Despite some shortcomings and the extra work required to make it usable, I love the new (to C++ projects anyway) MSBuild system and the new native multi-targeting feature that came with it. The MSBuild system is completely customizable, flexible, consistent, and standardized (unfortunately all the documentation assumes you’re already familiar with it, so it’s very daunting at first). MSBuild and native multi-targeting were the main reason I decided to move to VS 2010.
The switch away from the single inherited property sheet to the unlimited stack of property sheets is a very nice change, albeit a migration headache. In previous versions, these had to be maintained in a text editor; now they can be managed completely within the IDE using the familiar property page interface. This ranks as my second favorite improvement behind native multi-targeting.
VS 2010 still gets confused when you use the same source files in multiple projects, but less so than previous versions. In previous versions, source code was always parsed in the context of the first listed project of the solution that uses the file. In VS 2010, it is displayed in the context of the project you opened the file from. IMO it should switch with the active project, but at least you can now close a file and reopen it from the other project to view it in the context of the new project. This affects the display of Intellisense errors and graying of code hidden by preprocessor macros.
The Bad
There is no way to permanently turn off the display of Intellisense errors in the error list. You have to wait until one is displayed, then right click in the header area to turn them off. I guess in simple projects it might be useful to leave them on, but in all my projects they are numerous and useless.
The build system gets confused by multiple projects in a solution with different sets of configurations that don’t match the solution configurations one-to-one. Previous versions did too to some extent, but you could always fix these problems in earlier versions by setting build dependencies correctly in the solution file. In VS 2010, I have some projects that simply will not build correctly in some scenarios no matter how they are set. There are several different manifestations of this problem: batch builds that build projects in the wrong order, rebuild all resulting in a project getting cleaned a second time after it has already been rebuilt (hence not being available when a referencing project needs it), and batch builds that don’t build referenced projects which are selected to build but which are not selected in the active solution configuration.
Utility and MakeFile projects cannot have output files set, which means e.g. deployment projects that consume their output will end up empty handed. In addition, they can delete files indiscriminately when cleaning. I found a partial workaround to these problems by changing the project type to Application, and giving each project a unique intermediate directory — but that requires a bit of extra work.
Migrating complex projects is far from automatic. A lot has changed, and while VS 2010 does a decent job of migrating things from earlier versions, I had to do moderate to massive manual work after the migration to every single one of my migrated projects. For example, the migration resulted in odd and incomplete project configurations named “Template” being left in the converted project files that had to be manually removed in a text editor. Build rules required some manual work in some cases. I also had to convert all my Utility and MakeFile projects to Application projects, which required some manual rewiring.
Visual Studio has gotten larger and slower. It takes longer to start than VS 2008, it’s slower to start a debuggee, and some common actions like going to a symbol definition occasionally and unpredictably result in interminable minutes-long delays during which the UI is completely unresponsive.
Visual Studio caches some open files. In some cases, this means that files cannot be deleted until Visual Studio is closed. I’ve also seen cases where the file was not held open, but changes were ignored until Visual Studio was closed and restarted. That one resulted in some hair pulling until I figured out that I have to close and restart Visual Studio if I modify certain MSBuild related files (most notably, *.props files).
The Ugly
Lockups. I’ve had several cases where VS 2010 locked up so tight even task manager couldn’t get a word in edgewise, and I ultimately had to hard reset the computer. Previous versions lock up and crash as well, but I can almost always clear the cobwebs by killing the process. In VS 2010, there are several background worker processes involved as well, and things can get a bit uglier when those background processes get in on the action.
I have never been able to single step a 32-bit debuggee on my 64 bit Windows 7 machine. I was hoping Visual Studio 2010 would fix that, but alas, it’s still broken.
Finally, there is one bug that drives me absolutely nuts. It has dogged Visual Studio since forever, and I’m sorry to say that Visual Studio 2010 still has it. The bug is that certain actions cause every merge module and deployment project to be expanded in Solution Explorer. I meticulously build a solution explorer sand castle by setting the state of every node in my complex and sometimes deeply nested projects. Then suddenly and without warning, something as simple as going to a symbol declaration causes Visual Studio to crawl from one end of the solution to the other, exploding every carefully collapsed deployment project node. It is such a helpless feeling, like watching the waves slowly and tauntingly wash away your sand castle, all the while knowing that you have no choice but to wait patiently then rebuild it again when the storm passes. Why, oh why, didn’t Microsoft finally fix this?