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.

4

8 回答 8

4

我创建了一个工具来比较和合并解决方案文件（http://slntools.codeplex.com）。与“通用合并”相比，将解决方案与该工具合并要容易得多。它无法处理项目文件的想法。

于 2009-04-13T04:00:08.627 回答
3

项目：Merge是我用来比较和合并 XML 文件的工具。我最初写它是因为我在使用 Visual Studio 项目文件时遇到了这个问题。

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

于 2010-08-14T20:46:06.673 回答
1

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

于 2012-06-13T15:58:53.823 回答
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.

于 2008-12-16T19:24:29.477 回答
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.

于 2008-12-16T19:29:38.580 回答
1

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

于 2010-07-25T13:38:40.043 回答
0

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

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

于 2012-10-29T07:50:01.217 回答
0

我编写了一个小的 Perl 脚本来合并解决方案文件：
http ://blog.tedd.no/index.php/2011/01/06/merging-multiple-visual-studio-solution-sln-files-into-一/

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

于 2011-01-06T13:36:37.797 回答