Visual studio 合并vcproj文件-SCM'；这是地狱

在源代码管理中执行合并的开发人员/SCM管理员中，合并项目/解决方案文件是一个众所周知的灾难

以一个常见的场景为例：在两个不同的分支中对项目/解决方案进行开发。当回到主开发线时，VCPROJ（和SLN）之间的相似性很小

原因是，VisualStudio可能会更改（并且确实会更改）这些文件中各种类似XML元素的位置。例如，配置调试和发布可能会在项目文件上的每次保存操作时交换顺序。这使得不考虑自动合并就不可能轻松地合并来自每个开发分支的更改

我可以假设Microsoft正在使用某种perl哈希系统来保存vcproj结构，因此保存操作时文件的呈现是不有序的

我首先想问：有没有人找到一些优雅的方法来解决这个问题

第二，我想提出两个建议：

• 请让Microsoft重新实现上述文件，并将其限制为某些严格的元素顺序

• 找到一个工具（或编写一个），可以按字母顺序、递归方式（元素中的所有元素等）对vcproj（xml格式）和sln（sln格式…）文件进行排序。在源文件和目标文件上使用此工具可以轻松地指出（并合并）更改，希望VisualStudio能够读取已排序、合并的项目或sln文件

---

任何其他的想法和想法都是受欢迎的。

< P>您可能想考虑将工具与SCM内的触发器相关联（如VPN的重新提交钩子），以便执行这些文件中的重新排序。

---

然后您将有机会有效地将这些元素合并在一起。

我通常会尽量避免将自动生成的文件放在SCM下。自动生成的文件应该由开发人员控制的源文件生成，这些文件可以放在SCM下。如果某个特定工具以不透明且脆弱的格式存储数据，这就是该工具的问题

---

关于VisualStudio，尽管我认为它有不错的编译器、库和调试环境，但我认为生成（PRJ、SLN、RC）中的文件存在很大问题。除了您提到的问题之外，它们在不同的VS版本之间也有很大的变化。因此，我们编写自己的make文件，并使用make在外部构建程序。此外，我们将资源文件拆分为我们不得不依赖于VS的部分，以及我们可以用普通编辑器正常处理的部分。我们从高级描述中自动生成许多资源文件，这些描述是用自定义领域特定语言编写的。因此，我们将难以在SCM下处理的更改的影响降至最低。

我创建了一个工具来比较和合并解决方案文件（）。与“通用合并”相比，使用该工具合并解决方案要容易得多。它无法处理项目文件。

我们对资源文件（项目文件没有那么多麻烦）所做的是在合并之前对它们进行排序。我们已经在Plastic上配置了merge命令，以便在合并之前实际运行排序（我们为此开发的另一个应用程序，如果您感兴趣，我们可以共享代码，没有什么特别之处），因此所有随机重新定位都会消失。。。希望有帮助。

是我比较和合并XML文件的工具。我最初编写它是因为我在VisualStudio项目文件中遇到了这个问题

---

它能正确地检测XML文件中重新排序的元素和/或属性，并能正确地自动解决几乎所有的“冲突”。

我编写了一个小型Perl脚本来合并解决方案文件：

---

可以修改脚本以满足您的需要。

检查安装选项-确保您的所有同事都安装了x64编译器组件（或都没有安装）

有一个名为gyp的google项目，它生成Visual Studio解决方案和类似于CMake的项目。该项目的一部分是python工具，用于分别对.sln和.vcproj文件的xml节点和属性进行排序：pretty_sln和pretty_vcproj。您可以从中独立下载它们

---

到目前为止，我只看了pretty_vcproj，它还扩展了导入vcproj的.vsprop文件，可能是为了比较两个vcproj的确切内容。虽然生成的vcproj不符合Microsoft提供的模式，但它可能工作得很好，或者可以将其更改为仅对“配置”和“平台”节点进行排序，而保留其他所有内容。不确定这是否值得，因为似乎已经有其他项目针对规范化vcprojs…

我喜欢你的工具想法。在我看来，拥有它是一件有用的事情。也许我会尝试一下……您对元素顺序在解决方案文件中不重要有多大信心？比如说，在ProjectSection（ProjectDependencies）和GlobalSection（TeamFoundationVersionControl）部分中？任何地方都有发布的格式吗？我刚刚尝试过，但在比较由VS和SD编辑的项目时，它会给出错误。