Pitfalls in Upgrading from Visual Studio 2005 to Visual Studio 2008

Question

I've read a number of posts touting the merits of migrating from VS 2005 to 2008. However, I'd love to hear what the various pitfalls are in actually doing the migration. We're about to migrate and I'd prefer knowing what speed bumps to anticipate and plan for instead of discovering them by surprise along the way. Any helpful guidance on this would be much appreciated so that the process is as painless as possible.

Oh, we're primarily a C++ development house, with a handful of moderate size products and a bunch of small ancilliary tools. We use external makefiles for everything so that all builds are readily automated. Specific insights about what to expect when migrating this type of development operation would be most helpful.

Thanks in advance for the help!

Answer 1

The only issue I have had with Visual Studio 2008 is that it was quite slow until I tweaked it a bit. I was running into a delay coming out of Debug mode on the order of 8-10 seconds or so - was quite annoying. SP1 helped out as did modifying some IE settings.

But otherwise, I've been happy with it.

Answer 2

On the off chance you use any Visual Studio plugins, you may experience compatibility problems - when we first switched to it, there wasn't a version of Resharper out yet that supported 2008, so that was a minor issue at the time. Beyond that, we haven't really had any problems with the IDE itself. That being said, we don't do a lot of C++ so I'm not sure how different your situation may be.

Come to think of it, the only other problem we had with the switch involved building .Net 3.5 apps with nant. You didn't say what build tools you use or if you do any managed code so I'm not sure if this would be a problem for you. If it is, there are some workarounds on the net for getting nant to work with 3.5 apps which involve tweaking nant's config files. Let me know if you'd like me to post it.

Answer 3

We just finished upgrading this past month. I haven't noticed a slowdown - but we have been running SP1 from the start. We made the mistake of installing a Beta version of SP1 (beta for a service pack?!?!) and had to download and run a special tool to remove it before installing the RTM SP1, but that should not affect you. The biggest pain has been building all our third-party libs for 2008 and getting a batch process working to back-convert our projects and solutions to 2005 for one of our customers. About the libs - Microsoft says if it has any C++ in the public interface, OR uses STL internally then it needs to be rebuilt with the new compiler. I wrote up a little synopsis on my blog.

Edit: Here is the project converter that we used. I converted it to a command line app for our batch process, and it works pretty well.

Answer 4

My previous company's upgrade experience was as follows:

• We experienced greater reliability, especially as we had apps that were heavily multi-threaded and were a pain to debug.
• VS2008 was substantially faster and less RAM consuming (at least with a solution with 50 projects).
• Some of our C++ Code would no longer run on NT systems. This is resolvable by using an old editbin executeable (e.g. from VS2003) to modify the binary as part of a post event.
• Once you upgrade to VS2008, the project file is also updated for that. So if you have to go back and forth between the two IDEs (e.g. not all developers have transitioned) then there may be problems.

Answer 5

We've found it to not be totally reliable; most of the time it's fine, but a couple of us have had days where it just seems to crash every five minutes. Frankly it feels a little buggy too, eg. there's some itinerant bug with resources that SP1 hasn't fixed for us.

Some "link time code generation" thing got turned on apparently automatically during the migration, and IMO it's too slow. Link times going from 30 seconds to 7 minutes were pretty hard to swallow. Turned that back off again...

On the plus side, debugging is considerably faster, which is a big plus when you have a bug in some time-consuming code. We're not convinced about release build speeds though.

Still, there might be lots of wonderful features in other languages, but as far as I can see the Visual C++ team apparently haven't been that busy in the intervening three years (or maybe there are only like two of them left?).

Answer 6

Reliability much improved. Everyday feature set unchanged (which is as it should be).

Answer 7

One gotcha I've encountered without being aware of the change (I have a question post on it too) Installers can behave differently. The old upgrade was more an uninstall and a reinstall. The new one does an in-place upgrade. This can lead to issues:

1. need to put version info into DLLs - no bad thing, but may not be a step ytou've automated

2. out of the box, a service can not auto-upgrade, you need to force the user to uninstall the old and then install the new (TODO: citation for my question post to be added here)

Answer 8

I have only ran into two problems.

1. A couple of 3rd party add-ins did not work when we first moved to 2008 with the RTM. I do not remember which ones, but I have not run into this with any of the add-ins that we are currently using.

2. If you are using a Team Edition, or Team Suite, there are some 3rd party check-in policies that do not work because they referenced the 2005 TFS API. We were able to get around that by either recompiling with the appropriate references for things we had code for (like things pulled down from CodePlex) or rewrote the policies, since they are fairly simple.

Like I mentioned, the only issues we had were with 3rd party extensibility, and no issues in months.