为什么C#设计器生成的代码(如Form1.designer.cs)会对Subversion造成严重破坏?

我的工作室最近从SourceSafe切换到Subversion,让我们从自动锁中解脱出来。 这导致了对Forms的并发编辑,这很棒。 但是当多个开发人员提交更改时,设计人员创建的代码文件(所有名为TheFormName.designer.cs的文件)都会导致很难解决的冲突。

据我所知,这是因为设计师生成的代码会在用户修改时重新安排,无论实际更改有多少。

  • 如何让这些冲突更容易解决?
  • 有没有办法告诉设计师修改代码?
  • 经验丰富的C#团队如何处理表单的并发修改?

我不熟悉C#或Windows窗体设计器,但是看一些我可以在网上找到的designer.cs文件,它们没有特别复杂的结构。

它的哪些部分正在重新安排? 我想这主要是InitializeComponent()方法中属性的顺序混乱了吗?

如果是这种情况,您可以编写一个简单的脚本,按字母顺序重新排序这些行,特别是如果您从不手动编辑这些文件,并将其用作Subversion中的预提交钩子脚本 。

嗯,对吧……划伤那个。 该部分底部的大红色框表示您不应该在钩子脚本中修改事务。 但是你可能能够找到另一种方法来在改变的designer.cs文件和提交它之间的某个地方运行该脚本。

编辑:

实际上,鉴于scraimer对此的评论:

完全破解,但在最糟糕的情况下,就在合并之前,我可以对BOTH文件进行排序,并使合并只是一个逐行的事情……

难道你不能让Subversion设置外部合并程序吗? 我一直在使用KDiff3 ,它可以在进行差异或合并之前运行预处理器命令 ,因此您可以自动执行该过程。

以下是一些尝试:

  • 使事物更加模块化。 使用用户控件等组件将表单拆分为多个较小的物理文件。
  • 使用表达层设计模式(如MVP)将代码移出视图并转换为标准POCO类。
  • 最新版本的SVN允许您使用硬锁 – 使用它来避免复杂的合并方案。

希望有所帮助。

我很确定这个问题没有灵丹妙药,因为设计师在整个designer.cs上踩踏板。

我所能建议的是尽量减少设计师的使用。 就个人而言,我只挂钩代码中的事件,只使用设计器进行初始化和定位。 因此,在变更集中理解差异并不太难(“哦,有人添加了一个按钮”,“哦,有人改变了它的外观”)。

是的,设计师的随机重新安排肯定是恼人的。 Microsoft是否使用自己的工具? Microsoft会查看他们检查版本控制的内容吗? 它令人难以置信。

我们团队的“解决方案”是在我们完成编辑后手工编辑Designer文件,将事物放回原位,以便基于文本的差异可读,因此可以合并并发更改并发更改。 幸运的是,Visual Studio的大部分重新排列都很简单,所以这很有用。

遗憾的是,我们发现此步骤对于validation正确性是必要的 – 我们发现Designer默默地删除了所需的东西,导致代码损坏。 因此,必须完成此步骤以解决潜伏在内部的任何数据破坏性错误。 叹。

由于微软在修复bug方面的记录很差,唯一的解决方案可能就是改进Mono的WinForms Designer,以便它能够在黄金时段完成。

我所知道的唯一方法是在使用合并样式源控制系统(如subversion)时真正避免此问题,即手动编码表单而不使用设计器。 显然,这不会很好,因为手工编码这些表格可能需要一段时间。

发生这种情况的原因是因为控件属性是由设计者按照它们放在表单上的顺序序列化的。 剪切和粘贴可以影响此顺序以及移动控件以使其具有新的父级(例如,当控件直接在表单上时将控件移动到面板上)。

我在一个大项目中遇到了这个问题,不得不采用一种相当丑陋的方法 – 将designer.cs文件与登记目标修订版区分开来,并使用合并工具手动合并它们。 这不是理想的,但这是我看到它与svn或其他合并样式源代码控制工具一致的唯一方法。

另一种选择是使用带有源控制的锁定方法,正如其他人所指出的那样,但这也带来了令人不快的副作用。