What is the experience when moving to VS10?

Question

We're thinking of upgrading a very large product to VS10.

I've heard a lot of good things about VS10 and am very excited about the new C++0x features however when playing around with VS10 I had one case in which a sample toy application crashed (which it didn't in VS8) and one case in which there seems to be a compiler bug in some C++0x features.

In another case I see that unorderd_map throws a bad_alloc exception where it doesn't do so in VS9.

Our product is made up of native C++ and .NET and is several million lines of code. Does anyone have any experience with migrating a comparable project to VS10? Was the process painful? and were there any regressions created by the move?

I'm looking for more anecdotal evidence since all the reviews I found online were good and don't match my experience.

Answer 1

The best feature in VS2010 for c++ besides the c++0x features is that you can disable intellisense more easily. It's now a built-in option.

You can even tell intellisense to only parse and index files that appear in your solution. That way if you include a boost header, or just a really huge code base, it doesn't try to index it and crash like in VS2008 and 2005.

Answer 2

While I've only migrated a small native C++ application (~100,000 lines) to Visual Studio 2010 I've yet to encounter any compiler bugs.

It's been my experience (both with this application and other, larger, applications) that upgrading to the latest version of Visual Studio is worth the time and effort. Visual C++ gets better with each release so the risk of new compiler bugs is generally offset by improvements to the compiler, standards compliance, and the development environment.

Answer 3

Two things that have annoyed me as part of the move:

1. Managed c++ projects are forced to reference .Net 4 framework if you use VS2010 tools (you can fiddle behind the scenes and keep the VS2008 tools so you can target .Net 3.5 etc)

2. Something was funny with the output paths in my managed c++ DLLs that caused them to have a path\\path rather than path\path in the project files. This resulted in VS2010 not being able to use the DLLs as references to other projects.

Both of these were not show stoppers for me, but were unexpected when I upgraded my projects.

Answer 4

We also have a similar large project. I haven't run a line-of-code counter, but I'd guess there's easily a million. There's approx 200 projects - about 140 c++ projects, all using COM/DCOM and 60-odd .NET ones using various combinations of Winforms/WPF/etc. We have a lot of COM interop and PInvoke

We were previously on VS2008 for C++/C# and targeting the .NET framework 3.5SP1, and have moved to VS2010 for C++ and targeting .NET 4.

Overall Impressions:

• The upgrade wasn't too painful overall. It took about a day to get it up and running then another couple (spread out amongst various devs) to iron out other remaining issues

• Personally I find VS2010 better than 2008, but it's not that major of an upgrade. The benefits come from the language improvements (C++ 0x and .NET/C# 4)

• Projects are not backwards compatible. Your entire team all has to make the jump at once.

• It does fix a few annoying things though like the add reference dialog, and the stupidly long amount of time it used to take context menus on projects to appear

• The IDE crashes a lot less than 2008 did, but it still crashes every couple of days.

• The new VS2010 add-ons are quite neat

• The "multi-monitor" support is not much "support". You can float lots of single code windows outside the IDE, but you can't dock them together. Basically you get tabs on your primary screen, and lots of floating windows on your secondary screen which is fairly useless.

• ClickOnce still sucks!

• You don't have to upgrade your build machine. Just install VS2010 on it and tweak the TFSBuildService config so it knows about .NET 4

C++

• DO NOT install the "Power Commands" addon. It screws up the IDE when working with C++ projects. (basically it makes the IDE lose and gain focus about 100x a second which means you can't select text or use keyboard shortcuts properly)

• The C++ project format has changed from .vcproj to .vcxproj. The visual studio project upgrade wizard takes care of most things, but it did lose a few pre/post build steps which we had to manually put back in place.

• You can use VS2010 and still target the VS2008 C++ compiler. We initially did this after migrating the projects, as we were being cautious. It wasn't a huge deal switching over to the VS2010 compiler so we went for it after a day or two - we had it throw some asserts at us from the STL, but these things were technically incorrect anyway so we just fixed them.

• The main issue we had with upgrading the C++ projects is that project dependencies are now stored in the .vcxproj files, and NOT in the solution. You know how you right-click on a project, select "Dependencies" and tick the boxes for the dependencies? This still affects building in VS2010, but MSBuild pays no attention to it. This means your build-machine builds will almost certainly break because the build order will be wrong. You have to bring up the properties page for a project, select "Framework and References" and put the dependencies in there instead.

• This also means that if you need to build a pure native DLL before a .NET dll (say because you PInvoke it) you can't rely on the build order working! We had to manually edit the .csproj file of the .NET project and stick a "reference" to the native project in. This causes VS to throw a compiler warning, but it's the only way to make it build things in the right order

• auto in C++0x is the bees knees.

• The VS2010 C++ compiler takes almost exactly the same amount of time to compile our code as the 2008 one did.

.NET:

• Upgrading C# projects is a non-event. Most of the issues we had were due to conflicts where we'd manually backported some classes (like Tuple) ourselves and had to delete the backports.

• .NET 4 is astonishingly happy to load old .NET 3.5 code. One of our developers had made a custom fork of the entire codeplex WPFToolkit (don't ask, sigh). Microsoft folded this toolkit into the .NET core in 4.0. I thought we'd have a ton of conflicts from this, but we just loaded the forked toolkit dll and everything worked seamlessly.

• The annoying exception to this is unit tests. You can build .NET apps in 2010 that will target v2,3, or 3.5 of the .NET framework, but visual studio can only load unit test projects that target .NET 4. If you're using the built in visual studio unit testing, this means no multi-targeting for you.

• Fixing the non-blurry text in WPF is great. Why the heck they shipped for years with a broken text renderer I'll never know.

• They've tightened up some of the COM interop stuff. We had a few issues where .NET threw an error because the calling convention on our pinvoke signatures was wrong - 3.5 would silently fix this up for you. These are easy to fix though

If you have any more questions, feel free to ask :-)

Answer 5

@Orion Edwards

You know how you right-click on a project, select "Dependencies" and tick the boxes for the dependencies? This still affects building in VS2010, but MSBuild pays no attention to it.

This is definitely not correct, and does not happen in the general case (or everyone would be at our door). Please open a Connect bug, so we can look into this and fix it.

Thanks -- Dan/msbuild.