Microsoft Visual Studio使用XML来保存其.vcproj
项目文件。因此,应该很容易区分XML项目文件。
不幸的是,如果您更改任何项目文件的属性,Visual Studio会坚持随机改组项目文件的XML节点!这使得项目文件更改的文本差异和合并基本上不可能。更改一个编译器设置可以使我的视觉差异工具认为我已经改变了文件中50%的行!我甚至尝试过一些XML diff工具,但它们只是显示了一个更加结构化的同一个视图。
有没有人建议在源代码管理中维护.vcproj
个文件?或者说服Visual Studio 不重新排列.vcproj
文件中的XML节点?
(我还调查过使用像CMake这样的工具从更加差异友好的文本文件生成.vcproj
文件,但CMake有自己的问题。)
答案 0 :(得分:5)
这似乎时不时出现。
对于插件或其他规范化工具来说,这可能是个问题。
这将是一个伟大的副业,直到MS决定解决它。然后你运气不好 - 除非他们提议购买你的IP。
是否有人想要启动开源项目或商业产品?我是游戏。
我可能会使用独立的规范化工具,然后看看我是否可以将其变成插件。
答案 1 :(得分:4)
我们现在正在看到这个,项目文件中的配置在几台人的计算机上重新排序,这非常令人沮丧......
* 注意: 我们都使用VS 2008 Pro,而非团队
起初看起来它们是随机重新排序的,但实际上有一个模式,它根本不是随机的。
对于一组,配置按平台排序,然后按Config:
排序对于另一组,配置按Config排序,然后按平台排序:
通过perforce历史记录,这与同一组人提交的多个项目一致,并且大约有50/50的分割,因此不仅仅发生在一个人身上。
这是你看到的同一个问题吗? 如果是这样,我希望这种模式有助于找到一个不涉及宏/额外差异步骤的解决方案......
它必须是某个地方的设置,或点击某些东西的副作用,因为每台这些机器100%可重复。即使你选择初始环境布局(VC ++,VB,General Development等等)选择哪种选项也很愚蠢
答案 2 :(得分:2)
我使用WinMerge作为我的差异工具,我启用了移动的块检测。它并没有完全解决问题,但它使差异可视化更加可以承受。
答案 3 :(得分:0)
您在哪个版本的Visual Studio中看到了这个?
我使用.vcproj文件做了很多工作(我们在多个Visual Studio版本中为我们的库维护项目文件的版本,而且我总是在混淆和合并这些东西)但我从未见过这种行为。
答案 4 :(得分:0)
我在Adobe的团队在vs2008中看到了同样的事情。只是一个基本的调试/发布,win32 / win64项目为您提供4种配置和随机改组。有几个人试图找出devstudio重新排序的时间和原因,但目前认为排序的关键是关键字哈希 - 因此是半随机的。我们已放弃并在代码审查中总结了“真正的”变化。
答案 5 :(得分:0)
我想我已经找到了这次洗牌的原因。至少在VS2008中。
如果安装x64编译器,VS会将项目命令为:
Debug|Win32
Debug|x64
Release|Win32
Release|x64
如果你不这样做,它会点赞它们:
Debug|Win32
Release|Win32
Debug|x64
Release|x64
因此,请确保所有对等方都安装了相同的编译器集,因此不会随机播放。
测试它,此行为似乎是可重现的。