合并项目/解决方案文件是开发人员/ SCM管理员在其源代码管理中执行合并的众所周知的灾难。
例如，采用一种常见的方案：开发是在两个不同分支的项目/解决方案上完成的。当合并回主要开发线时，VCPROJ（和SLN）之间的相似性非常小。原因是，Visual Studio可能会更改（并更改）这些文件中各种类似XML的元素的位置。例如，配置调试和释放可以在proj文件上的每个保存操作上交换顺序。这使得无法轻松地合并来自每个开发分支的更改，甚至不考虑自动合并。
我可以假设Microsoft正在使用一些perl散列系统来保存vcproj结构，因此在保存操作时不会对文件进行渲染。
我首先想问：有没有人找到一些优雅的方法来解决这个问题？
其次，我想提出两点建议：
让Microsoft重新实现上述文件并将其限制为某些严格的元素排序。
找到一个工具（或编写一个），按字母顺序，递归地（元素中的所有元素等）对vcproj（xml格式）和sln（sln格式...）文件进行排序。在源文件和目标文件上使用此工具可以轻松指向（并合并）更改，希望Visual Studio读取已排序的合并项目或sln文件。
欢迎任何其他想法和想法。
答案 0 :(得分：4)
我创建了一个工具来比较和合并解决方案文件（http://slntools.codeplex.com）。与“通用合并”相比，将解决方案与工具合并要容易得多。它无法处理项目文件。
答案 1 :(得分：3)
Project: Merge是我用于比较和合并XML文件的工具。我最初编写它是因为我遇到了Visual Studio项目文件的这个问题。
它正确检测XML文件中重新排序的元素和/或属性，并将自动正确解决几乎所有“冲突”。
答案 2 :(得分：1)
您可能需要考虑将工具与SCM中的触发器相关联（如SVN的重新提交挂钩），以便在这些文件中强制执行重新排序。
然后你就有机会有效地将这些元素合并在一起。
答案 3 :(得分：1)
我通常会尽量避免在SCM下放置自动生成的文件。应该从开发人员控制的源文件生成自动生成的文件，这些文件可以放在SCM下。如果某个特定工具以不透明和易碎的格式存储数据，这就是该工具的问题。
关于Visual Studio，虽然我认为它有不错的编译器，库和调试环境，但我相信生成的文件（PRJ，SLN，RC）存在很大问题。除了你提到的问题，它们在不同的VS版本之间也会发生很大的变化。出于这个原因，我们编写自己的makefile，并使用make在外部构建程序。此外，我们将资源文件拆分为我们不得不依赖VS的部分，以及我们可以使用普通编辑器理性处理的部分。我们从高级描述中自动生成许多资源文件，使用自定义域特定语言编写。因此，我们将SCM难以处理的变更的影响降至最低。
答案 4 :(得分：1)
答案 5 :(得分：1)
检查安装选项 - 确保所有同事都安装了x64编译器组件（或者所有未安装的
）答案 6 :(得分：0)
我编写了一个小的Perl脚本来合并解决方案文件：
http://blog.tedd.no/index.php/2011/01/06/merging-multiple-visual-studio-solution-sln-files-into-one/
可以修改脚本以满足您的需求。
答案 7 :(得分：0)
有一个名为gyp的Google项目可以像CMake一样生成Visual Studio解决方案和项目。该项目的一部分是python工具，分别对.sln和.vcproj文件的xml节点和属性进行排序：pretty_sln和pretty_vcproj。您可以从http://gyp.googlecode.com/svn/trunk/tools/
独立下载它们到目前为止我只查看了pretty_vcproj，它还扩展了导入vcproj的.vsprop文件，可能是为了比较两个vcprojs的确切内容。生成的vcproj不符合Microsoft提供的模式，但它可能工作正常，或者可以将其更改为仅对“Configuration”和“Platform”节点进行排序，而其他所有内容都保持不变。不确定是否值得付出努力，因为似乎有其他项目已经针对规范化vcprojs ......