Suggestions for maintaining Visual Studio vcproj project files in version control

Question

Microsoft Visual Studio uses XML to save its .vcproj project files. So diffing XML project files should be easily.

Unfortunately, if you change any of the project file's properties, Visual Studio insists on randomly shuffling the XML nodes of the project file! This makes textual diffing and merging of project file changes basically impossible. Changing one compiler setting can make my visual diff tool think I've changed 50% of the lines in the file! I've even tried some XML diff tools, but they just show a more structured view of the same mess.

Does anyone have any suggestions for maintaining .vcproj files in source control? Or a way to convince Visual Studio to not rearrange the XML nodes in the .vcproj file?

(I have also investigated using tools like CMake to generate .vcproj files from a more diff-friendly text file, but CMake has its own problems.)

Answer 1

This seems to come up every now and then.

• Merging vcproj files - SCM's hell

Perhaps it is a problem ripe for a plug-in or other normalizing tool.

It would be a great side-business, until MS decides to fix it. Then you're out of luck - unless of course they offer to buy your IP.

Anyone want to start an open source project, or commercial product? I'm game.

I might have a go at a stand-alone normalizing tool, then see if I can turn it into a plugin.

Answer 2

We are seeing this here at work now, with project files where the configurations are reordered on several peoples computers, and it is very frustrating...

*Note: We all use VS 2008 Pro, not Team

At first it looks like they are randomly reordered, but there is in fact a pattern and it is not random at all.

For one group the configurations are ordered by Platform, then by Config:

• Debug|Win32
• Debug|x64
• Release|Win32
• Release|x64
• Debug DX11|Win32
• Debug DX11|x64
• Release DX11|Win32
• Release DX11|x64
• ...

For the other group the configurations are ordered by Config, then by Platform:

• Debug|Win32
• Release|Win32
• Debug DX11|Win32
• Release DX11|Win32
• Debug|x64
• Release|x64
• Debug DX11|x64
• Release DX11|x64
• ...

Looking through perforce history, this is consistent with multiple projects submitted by the same sets of people, and there is about a 50/50 split, so it is not just happening for one person.

Is this the same issue that you are all seeing? If so, I hope this pattern helps find a solution that does not involve a macro/extra diff step...

It has to be a setting somewhere, or a side effect of clicking something, since it is 100% reproducible per each of these machines. Even if it is something silly like which option you choose for your initial environment layout (VC++, VB, General Development, ect...)

Answer 3

I use WinMerge as my diff-tool and I enabled the moved block detection. It doesn't quite fix the issue, but it makes visualizing the differences a little bit more bearable.

Answer 4

Which version of Visual Studio are you seeing this in?

I do a lot of work with .vcproj files (we maintain versions of the project files for our libraries in multiple Visual Studio versions, and I'm always diffing and merging the things) but I've never seen this behaviour.

Answer 5

My team at Adobe has seen the same thing in vs2008. Just a basic Debug/Release, win32/win64 project gives you 4 configurations and random shuffling. Several people have tried to figure out when and why devstudio reorders, but current thought is the sort key is a keyword hash - hence semi-random. We've given up and in code reviews just summarize the "real" changes.

Answer 6

I think I've found the reason for this shuffle. At least in VS2008.

If you install the x64 compilers, VS will order projects as:

Debug|Win32
Debug|x64
Release|Win32
Release|x64

If you don't it will order them like:

Debug|Win32
Release|Win32
Debug|x64
Release|x64

So make sure all your peers have the same compiler set installed, so it won't shuffle.

Tested it and this behavior appears to be reproducible.