At work I have been migrating our source tree from Visual Studio 2005 to Visual Studio 2008. Our source tree supports several top-level products, and contains more than 100 C++ projects. Additionally, we (like most shops, I suspect) have a number of third-party libraries upon which we depend for various tasks like image processing and 3D graphics. The port has been surprisingly difficult tedious. Some may remember the bad-old-days of porting from the 7.1 compiler to the 8.0 compiler – it wasn’t anything like that. However there was very little guidance out of Microsoft as to what type of problems C++ developers could expect to encounter. I suspect this is just another instance of C++ being treated as the step-sister to C# and the other .NET languages. For example, none of the cool new designer stuff was added to Visual C++. Microsoft’s changes to Visual C++ pretty much amounted to buying a third-party library so MFC developers could have the Office Ribbon. Sigh…
I think what would have made me happy would have simply been a porting guide from Microsoft – but since I couldn’t find one, here’s my take on compatibility between the two versions, included here for the purpose of helping any other poor soul that traverses this path.
There are several aspects to “compatibility” between VS2005 (VS8) and VS2008 (VS9)
- Project and Solution file format
- Native DLL & Library binary compatibility
- Compiler Issues
- .NET version for managed code
Project and Solution file format
The project and solution files for VS9 are different than those for VS8. The differences are mostly trivial, but break compatibility nonetheless, see Rick Strahl’s blog for more info. Emmet Gray has a project converter that will convert back and forth between these two versions. I downloaded it and am trying it out for situations when we have to give a customer projects for Visual Studio 2005.
Native DLL & Library binary compatibility
Microsoft says that DLLs, and some static libs with pure C-style interfaces should work identically between VS8 and VS9. However, if a static library compiled for VS8 uses the STL, or some other library internally (not just in the public interface), or has a C++-style public interface, then it should not be used with VS9. This post on MSDN has more information. We found that libraries like OpenGL and Intel’s Performance Primitives seem to work fine (because they are C-style DLLs), but we had to rebuild libraries like Boost and GDAL. I also had to turn off Enable Minimal Rebuild (/Gm) and Detect 64-bit portability issues settings – though that may have been because I was compiling with the multiprocessor flag (/MP) turned on.
As Microsoft moves toward a more standards-compliant compiler with each release, they deprecate certain flags and options, as well as APIs and code constructs. Consequently, code that compiled under a previous compiler sometimes needs minor tweaks to work with the newer compiler. The changes from VS8 to VS9 are fairly minor, especially compared to the jump between VS7.1 and VS8. The only thing I ran into was that _MIN() and _MAX() are now deprecated. You are now supposed to use
.NET version for managed code
This is the compatibility issue everyone seems to talk about. VS9 does support multi-targeting, which allows previous versions of the .NET API to be targeted. I have not personally tried it out, but I did see the Targeted Framework setting (or something like that) in the project options for C++/CLI projects, as well as (obviously) C# projects.
Well, that’s about it. Hope your port goes smoothly!