Allowing developer-specific settings in VS2008 Native C++ projects

Question

Is it possible to combine the following properties, and if so, how?

• Store in our version control system some Visual Studio 2008 native C++ (VCPROJ) project files for the developers in our team that use this IDE.
• Allow some of those developers to tweak their projects (e.g. using debug version of third-party libraries instead of the usual ones).
• Make sure these modifications are done in files that are not versioned.

In other words, I would like to allow developers to tweak some settings in their projects without risking that these changes are committed.

An 'optional VSPROP' file approach seems doomed to fail, as VS2008 refuses to load projects that refer to non-existent VSPROP files...

Any other suggestion? Is this possible with VS2010?

Answer 1

You may not be able to do this but using a solution that generates the vcproj like CMake for example would let you do this. Scripts all your project with CMake and literally conditionally include a config file(if present for example) that developers can change on their setup.

Answer 2

Well, as a preliminary solution you could put the project file into something like .hgignore or .gitignore after its initial commit. This way changes to it can't be done accidentally.

At least that's how I handle .hgignore itself.

Answer 3

We use a versionned "common_configuration" folder, and a script which copies project files from this "common_configuration" folder towards the "project" folder. We have another script to copy the configuration backwards, so the developpers need to make a conscious action to commit their local changes to the global version control system.

It answers partly your needs :

• The upside : we have a way to keep a common configuration for everyone, and no accidental committing of local configuration
• The downside : blindly copying the files actually crushes local changes. We live with it. We could write some more clever merger tool (using diff, or xml specific manipulations), but don't want to spend to much time on supporting the deployment tools.

Answer 4

Branches could solve this problem: you create a branch, play with different versions of third-party, merge changes to trunk if results are good.