Open source Visual Studio project distribution nightmare...

Question

Every time Microsoft releases a new version of visual studio, they always require me to convert my solution and project files to 'the latest version.' Even with something as simple as a "Hello World" solution, I need to go through their conversion wizard!

And, to make things worse, the new visual studio solution files aren't compatible with old versions of visual studio.

What a nightmare for anyone working with a group of people...or anyone hoping to distribute the source code for their projects.

Is there any good way to distribute a visual studio project, and allowing people using older versions of visual studio to still use it? It's a simple C program, not using any nifty options. I only have access to Visual Studio 2008, and Visual Studio provides no backwards 'conversion' wizard. Would it make sense to release the source code using nmake+makefile to build the program? It seems the nmake file format hasn't changed significantly in some time, and would be possible to provide a makefile that works with a wider range of versions of visual studio.

Answer 1

There is no simple answer. I wish we did, though. The situation is only getting worse with the fact that 2005 onwards you also need to pack in a redist pack or do a static linking with the runtime. And I haven't a clue as to what it will do if you have a 2008 static-linked binary talking to a earlier generation (earlier than 2005) application. According to MS, this should work.

Can you safely assume all your users will have a copy of Visual Studio? And are they all running the same version? (I know, the express edition is free nowadays...) You will need to educate your user base on the difficulties if you continue to pursue this path and have them all use the same version of VS2008 to make life easier for everyone around.

I would rather use make/gcc than having go round the park, though.

Answer 2

I think using nmake is the way to go - unfortunately VC6 is the last version that would automatically create one for you based on the project.

However, you say your project is pretty simple, so this shouldn't be a major barrier.

Answer 3

You could use CMake as the build tool for your project. It will generate VS project files for you, and you can just open the file and use it to build the project. The conversion problems won't matter, because you can just use CMake to build it again.

The advantage of CMake in this case is portability and version-independence (also cross-platform build capability, but that may not be relevant). CMake does, however, have a bit of a learning curve to it and it's not quite as simple as just using a project file, but it does solve the problem you are experiencing. Since your project is relatively simple, it may be a solution for you.

Answer 4

The normal way to do this is to place the vs project files in a sub directories of the solution. Eg

solution
 - build
 -- vc6
 -- vc7
 -- vc8
 -project1
 -- src
 -- build
 --- vc6
 --- vc7
 --- vc8
 -project2
 -- src
 -- build
 --- vc6
 --- vc7
 --- vc8

Then when you get a new version of vs - copy the last project directory eg vc7 to vc8 - do the same for the solution - open the solution and project files in a text editor to fix any paths - finally open the solution in the new version of vs and let it convert your projects - (Use source control as if one or your paths are wrong it update a project in an old directory)

This is tiresome but you only have to do it every few years.

This is how we used to do it, but there is a better way however and that is to use CMake to generate your projects. We use this now in work and it allows use to use a single project definition to work natively on windows and unix. On windows we use vs projects on unix we use eclipse and makefiles. Also CMake allows you to abstract common project settings like compiler and linker flags, so they only have to be modified in one place.

I now use CMake for all c++ projects whether I require its multi platform capabilities or not.

Answer 5

I'd suggest you use the open source process. Release your code as VS 2008, and allow someone who uses earlier versions to contribute the solution file for those versions. That's the open source way.

Answer 6

One solution I have seen utilized by commercial Windows libraries is naming the solution files with the VS version as a suffix (eg: Project_VS2005.sln, Project_VS2008.sln, etc.). You still have to keep them in sync, but you don't have to change file paths, or include directories, or modify the actual solution files much; just keep multiple files, one for each VS version which is supported. You have to do the same thing for the project files, but at least you don't have to change the contents around to support different directory structures unless you want to support building side-by-side with multiple VS versions, and in the case where you do you only have to change the output settings for each different project file.

Not saying it's a great solution, but rather just another option.