Develop seamlessly in both VC++ 2010 and VC++ 2008 on the same work ?

Question

Hi,

I'd like to synchronize a VC++ 2010 project with a VC++ 2008 one. Is it even possible ? Basically, if I'm adding/deleting/renaming a file to a project in VS2010, I'd like it to be added/deleted/renamed to the corresponding VS2008 project. Project options synchronization would be awesome too, but not necessary. I don't need a solution-level synchronization either.

Edit: I've been suggested to "merge" the project files at check-in or build time with a script or tool. Unfortunately, VC++ project file format has changed from VS2008 to VS2010 and have nothing in common. So my question is more like: Is there a tool out there capable of merging/converting between vc9 and vc10 project files ? I might write my own tool if there is not any other way to address this.

Thanks.

Answer 1

You only can maintain those solution/project files separately. if you'll write your add-on please let me know!

Answer 2

Source control helps here. I have done this before with previous versions by making an upgraded (VS2010) branch and merging changes back and forth between it and the trunk (VS2008). While certainly not seamless, it works.

I don't know if the project changes in VS2010 would make it any better or worse than before!

Answer 3

I don't have 2010 installed at work so I'm going mostly from memory here. Very little has changed in the project file schema from 2005 to 2008 to 2010. For the most part I simply use a text comparison tool like WinDiff or BeyondCompare to highlight the changes and copy them from one file to the other. I haven't played with any of the web project types, but I'm assuming for the most part the same technique will work. Since their basically XML schema's you could also use an XML mapping tool to do the same job.

I did notice when I converted an open source project that 2010 really did not like ClickOnce project settings. It would convert fine, but would ask me to convert again every subsequent time I opened the project. I ended up having to completely remove the ClickOnce information from the project file in order to get it to stop.

EDIT: My experience is mostly based on the C# project schema, which hasn't changed much over time. As TheSamFrom1984 has pointed out, there are some big changes in the C++ schema that hasn't made it into the MSDN documentation on version 10 yet.

Answer 4

The Gallio OSS project is built using VS2010 while most of the contributors still use VS2008. To keep the *.csproj files synchronized with the *.vs2010.csproj files, we use a simple PowerShell script that runs WinMerge against every pair of project files. Nothing complicated, but very handy.

You can download the script at Google Code. To run it, just type the following command:

@echo off
powershell "& './Compare VS2010 Projects.ps1' -sync %*"

I hope it helps.

Answer 5

I believe the is a command line option to migrate a VS2008 project file to VS2010. So an option would be to only maintain the VS2008, and regenerate the VS2010 projects. The downsides are

• Not being able to enter VS2010 specific project options
• Any changes to the VS2010 project will be overwritten and not merged back to VS20008.

Answer 6

Visual Studio 2010 supports multi-targeting which will allow you to develop using VS2010 and downtarget the Platform tools to V9 so you can use the latest tools to maintain an older project. Why not just do that?

It comes with VS2010 and VS2008 for C++ out of the box, here is some info on settingup the VS2005 toolchain

http://weblogs.asp.net/israelio/archive/2009/10/20/enable-vs-2010-multi-targeting-also-for-vs2005-c.aspx

Answer 7

I did precisely this back when VS 2008 came out and we were evaluating it while the rest of the team were using VS 2005. I didn't want to commit any of the new format project files in as that would break it for the rest of the team, so I wrote a small script in ruby that just searched for all .vcproj files and renamed them to _2008.vcproj . I did the same for the .sln files too, but also searched for the references to .vcproj in the sln files and renamed that to _2008.vcproj so that it references the new projects.

Next, just load the new solution files and let the migration wizard do its thing (I assume VS 2010 has one just like the older versions). This lets you run both versions side by side. If anyone else in the team makes any changes to the old project file then simply re-run your conversion and then the wizard should just migrate the project that changed.

There's a further tweak you may need to add to the script which is to change the OutputDirectory and IntermediateDirectory fields in the vcproj file so that you're building to different directories too. If you do that then it means that you should be able to build with either version of Visual Studio on the same source tree.

Answer 8

You should treat the VS2010 copy as a Branch. Every couple days and upon any major change (Pending tests pass, of course), merge changes into the other Branch. This is a widely adopted and accepted practice in Enterprise software environments.

Answer 9

At my company we had exactly the same problem and chose to use CMake.

At least try it on one of your projects, it is the ideal solution for your problem.

It allows to describe our projects with a simple syntax in text files and then CMake generates VS2005, VS2008 and VS2010 projects from the same files.
This way only the Cmake files are modified and all the projects are updated at the same time.

In short CMake is:
1. clean
2. descriptive
3. native
4. safe

Because:
1. All the options and configurations can be read in the files, not in many properties panels.
2. The CMake grammar and syntax is easy to read.
3. All the generated projects are complete and independant from CMake.
4. You can use a Source Control Manager on the CMake files.

We had some solutions of 50 projects or 20 projects and it was a lot of work, and one of the reason we used CMake was because we needed to work with Xcode on Mac on some libraries which projects are now common for VS and Xcode.
But it would have been worth it even for the different versions of VS only.