Why does C# designer-generated code (like Form1.designer.cs) play havoc with Subversion?

Question

My workshop has recently switched to Subversion from SourceSafe, freeing us from automatic locks. This led to concurrent editing of the Forms, which is wonderful. But when multiple developers commit their changes, the code files created by the designer (all the files named TheFormName.designer.cs) cause conflicts which are very difficult to resolve.

As far as I can tell, this is because the code generated by the designer is heavily re-arranged whenever the user modifies it, no matter how little the actual change really did.

• How do I make these conflicts easier to resolve?
• Is there some way to tell the designer to modify the code less?
• How do you, the experienced C# teams, deal with concurrent modification of a Form?

Answer 1

Here are some things to try:

• Make things more modular. Use components like User Controls etc. to split forms into multiple, smaller physical files.
• Use presentation layer design patterns like MVP to move code out of views and into standard POCO classes.
• Recent versions of SVN allow you to take hard locks - use this to avoid complex merge scenarios.

Hope that helps.

Answer 2

I'm pretty sure there is no silver bullet for this problem as the designer stomps all over the designer.cs.

All I can suggest is to minimise the use of the designer. Personally I only hook to events in code and only use the designer only for initialisation and positioning. As such it isn't too hard to fathom differences in a changeset ("oh, someone has added a button", "oh, someone has changed how it looks slightly").

Answer 3

I'm not familiar with C# or the Windows Form Designer, but looking at some designer.cs files I could find online they don't have a particularly complicated structure.

What parts of it are being re-arranged? I guess it's mostly the order of the properties in the InitializeComponent() method that's jumbled up?

If that's the case, you might be able to write a simple script that re-orders those lines alphabetically, say (especially if you never edit these files manually anyway), and use that as a pre-commit hook script in Subversion.

Um, right... scratch that. The big red box at the bottom of that section says you're not supposed to modify transactions in hook scripts. But you might be able to find another way to run that script somewhere between the designer.cs file being changed and it being committed.

Edit:

Actually, given scraimer's comment on this:

Total hack, but in the worst case, just before a merge, I could sort BOTH files, and make the merge simply a line-by-line affair...

Can't you let Subversion set an external merge program? I've been using KDiff3, which can run a preprocessor command before doing diffs or merges, so you could automate that process.

Answer 4

The only way I know of to truely avoid this problem when using a merge style source control system such as subversion is to hand code the forms and not use the designer. Obviously, this would not be good because hand coding these forms can take a while.

The reason this happens is because the control properties are serialized by the designer in the order they are dropped on the form. Cutting and pasting can effect this order as well as moving a control so that it has a new parent (such as moving a control on to a panel when it was previously directly on the form).

I had this problem on a large project and had to imploy a rather ugly approach - diff the designer.cs files against the check-in target revision and manually merge them using a merge tool. This isn't ideal, but it is the only way I see this working consistently with svn or another merge style source control tool.

The other option would be to use a lock approach with source control, as others have pointed out, but this comes with unpleasant side effects as well.