我们的 QA 团队希望根据 EXE 和 DLL 在构建之间实际发生的变化来集中测试。 我们有一个很好的 svn 更改报告，但是源代码和更改的二进制文件之间的关系并不总是很明显。 我们正在比较的构建始终是完全干净的构建，因此我们不能使用文件系统时间戳。 我正在寻找用于比较 Windows（和 Windows CE）PE 二进制文件的工具，这些工具将忽略嵌入的时间戳和其他内容。 对于生成可靠的“哪些二进制文件真正发生了变化”报告的工具或其他方法有什么建议吗？ 谢谢。
澄清：感谢到目前为止的答案，但我们无法通过直接进行逐字节比较或比较校验和来生成报告，因为每次构建时所有文件都显示不同，即使源没有更改，因为编译器插入的时间戳。 问题是如何忽略误报。 拆解& 比较想法最接近我们需要的，我认为...
回答了！ Bindiff 正是我一直在寻找的。 非常感谢。
Our QA team wants to focus their testing based on what EXEs and DLLs have actually changed between builds. We have a nice svn change report, but the relationship between source and changed binaries isn't always obvious. The builds we're comparing are always full clean builds, so we can't use file system timestamps. I'm looking for tools to compare windows (and windows CE) PE binaries that will ignore the embedded timestamps and other cruft. Any recommendations for tools or other ways to generate a reliable 'what binaries have really changed' report? Thanks.
clarification: Thanks for the answers so far, but we can't generate the report by doing straightforward byte-for-byte compares or comparing checksums, because all the files appear different every time we build, even if the sources haven't changed, because of timestamps that the compiler inserts. The problem is how to ignore the false positives. The disassemble & compare idea is closest to what we need, I think...
answered! Bindiff is just what I was looking for. Many thanks.
发布评论
评论（8）
gnu binutils 特别是字符串
gnu binutils specifically strings
项目依赖关系图生成器 和 C++ 项目的依赖绘图器 都使用 GraphViz 可视化依赖关系。 我想您可以使用它们中的任何一个作为您的需求的基础，并在依赖关系图中特别突出显示源文件或其他叶子已更改的分支。
MD5 哈希值或校验和（如上所述）、忽略空格并过滤掉注释更改的简单差异或版本控制系统中的 changlist 信息都可以表明哪些文件已更改。
Project dependency graph generator and Dependency-Grapher for C++-Projects both use GraphViz to visualize dependencies. I imagine that you could use either of them as a basis for your needs with special highlighting of the branches in the dependency graph where source files or other leaves have changed.
MD5 hashes or checksums (as suggested above), a simple diff ignoring whitespace and filtering out comment changes, or changlist information from your version control system can signal which files have changed.
查看 NDepend。
Look at NDepend.
当我在公司开发用于安装验证的“自制”工具时，我们使用了Beyond Compare作为后端进行比较。
它具有出色的文件/文件夹比较（以及二进制）和脚本功能，并且可以输出 XML 报告。
When I was working on the "home grown" tool for installation verification at my company, we used Beyond Compare as a backend for comparison.
It has great file/folder comparison (binary as well) and scripting capabilities and can output XML reports.
您也许可以反汇编二进制文件，然后对程序集进行比较...
这听起来像是您的 QA 团队采取了错误的方法...对他们来说代码是什么样子并不重要；他们应该关心代码的外观。 只是它做了它应该做的事情。
编辑：
哦！ 再次阅读后，我发现我误解了你的问题。 我以为他们想测试已更改的方法...
在这种情况下，为什么不获取 MD5 哈希并比较它们呢？ 最微小的变化都会导致生成完全不同的哈希值。
You could perhaps disassemble the binary, and then do a diff on the assembly...
This sounds like your QA team is taking the wrong approach though... It shouldn't matter to them what the code looks like; just that it does what it's supposed to do.
Edit:
Oh! After reading it again, I realized that I misinterpreted your question. I thought they wanted to test the methods that had changed...
In that case, why not get the MD5 hash and compare those? The tiniest change will cause a totally different hash to be generated.
不确定哪种二进制文件（DLL？仅限 PE/WinCE 可执行文件？其他？）是否可以在二进制文件中嵌入版本信息，例如使用源代码控制标签在提交时更新源代码中的版本。 然后，当创建新版本时，二进制文件的版本字符串也会更新。 您可以使用版本字符串并检查其是否有更改，而不必比较二进制文件。
Not sure what kind of binaries (DLLs? PE/WinCE executables only? Other?)Is it possible to embed version information in the binaries, e.g. using a source control tag that updates the version in the source code on commits. Then when the new build is created, the binary would have it's version string updated as well. Instead of having to diff a binary file, you could use the version string and check that for changes.
我以前遇到过这个问题。 我的解决方案是编写一个工具，将 .EXE/.DLL 中的所有时间戳设置为已知值。 我会将其作为构建后步骤来运行。 然后二进制差异就可以正常工作了。
I ran into this problem before. My solution was to write a tool which set all the timestamps in an .EXE/.DLL to a known value. I would run it as a post-build step. Then binary diffs would work just fine.
您看过 Bindiff 吗？
Have you had a look at Bindiff?