26

Merging project/solution files is a well-known disaster among developers/SCM admins performing merges in their source control.

Take, for example, a common scenario: development is done on a project/solution in two different branches. When time comes to merge back into a main development line, there is a very small resemblance between the VCPROJ's (and SLNs).

The reason is, Visual Studio may change (and DOES change) location of the various XML-like elements within these files. E.g., Configurations Debug and Release may swap order upon every save operation on the proj file. This makes it impossible to easily incorporate changes from each development branch, not even considering an automatic merge.

I can assume that Microsoft are using some perl hashing system to hold the vcproj structures, hence the rendering of the files upon a save operation is not ordered.

I'd first like to ask: did anyone found some elegant method to workaround this?

Second, I'd like to make two suggestions:

  • Have Microsoft please reimplement the above files and restrict them to some rigid ordering of elements.

  • find a tool (or write one) that sorts vcproj (xml format) and sln (sln format...) files alphabetically, recursively (all elements within elements etc.). Using this tool on both source and target files would enable to easily point (and merge) the changes, hoping that Visual Studio reads the sorted, merged project or sln file.

Any other ideas and thoughts are welcome.

sth
  • 222,467
  • 53
  • 283
  • 367
  • I like your tool idea. it seems to me to be a useful thing to have. Perhaps I will have a go a it... – Tim Dec 16 '08 at 19:49
  • How confident are you that the order of elements is of no importance in the solution files? Say, within the ProjectSection(ProjectDependencies) and GlobalSection(TeamFoundationVersionControl) sections? Is there a published format anywhere? – Mal Ross Mar 17 '09 at 11:20

8 Answers8

4

I created a tool to compare and merge solution file (http://slntools.codeplex.com). It's a lot easier to merge a solution with the tool compared to a 'generic merger'. It cannot handle project files thought.

3

Project: Merge is my tool for comparing and merging XML files. I originally wrote it because I was experiencing exactly this problem with Visual Studio project files.

It correctly detects re-ordered elements and/or attributes within the XML file and will correctly resolve nearly all 'conflicts' automatically.

sth
  • 222,467
  • 53
  • 283
  • 367
1

Check installation options - make sure that all your colleagues have x64 compiler component installed(or all haven't)

Alex
  • 11
  • 1
1

What we do with resource files (not so much trouble with project files) is to sort them prior merging. We've configured the merge command on Plastic to actually run a sort (a different app we've developed for that, we can share the code if you're interested, nothing fancy) before merging, so all the random relocations go away... Hope it helps.

pablo
  • 6,392
  • 4
  • 42
  • 62
1

You might want to consider associating your tool with a trigger within your SCM (like a re-commit hook for SVN), in order to enforce the re-ordering within those files.

Then you would stand a chance to efficiently merging these elements together.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
1

I typically try to avoid putting automatically-generated files under SCM. Automatically-generated files should be generated from source files that a developer controls, and those can be put under SCM. If a particular tool stores data in an opaque and fragile format, this is the tool's problem.

Regarding Visual Studio, although I think it has decent compilers, libraries, and a debugging environment, I believe that the files in generates (PRJ, SLN, RC) are highly problematic. Apart from the problems you mention, they also change a lot between different VS versions. For this reason, we write our own makefiles, and build the programs externally, using make. Furthermore, we split the resource files into parts for which we are forced to rely on VS, and those we can sanely handle with a normal editor. We generate many resource files automatically from high-level description, written in custom domain-specific languages. We thus minimize the impact of changes that are difficult to handle under SCM.

Diomidis Spinellis
  • 18,734
  • 5
  • 61
  • 83
0

There is a google project named gyp that generates Visual Studio solutions and projects much like CMake. Part of that project are python tools to sort xml nodes and attributes of .sln and .vcproj files respectively: pretty_sln and pretty_vcproj. You can download them independently from http://gyp.googlecode.com/svn/trunk/tools/

I only looked at pretty_vcproj so far, it also expands .vsprop files imported into the vcproj, probably to compare the exact content of two vcprojs. The resulting vcproj does not conform to the schema provided by Microsoft though, but it would probably work fine, or one could change it to only sort the "Configuration" and "Platform" nodes, leaving everything else intact. Not sure if it's worth the effort, as there seem to be other projects directed at normalizing vcprojs already...

SvenS
  • 795
  • 7
  • 15
0

I've written a small Perl-script to merge solution files:
http://blog.tedd.no/index.php/2011/01/06/merging-multiple-visual-studio-solution-sln-files-into-one/

The script could be modified to suit your needs.

Tedd Hansen
  • 12,074
  • 14
  • 61
  • 97