问题标签 [binary-reproducibility]

有谁知道比较两个 .NET 程序集以确定它们是否是从“相同”源文件构建的方法？

我知道有一些可用的差异实用程序，例如 Reflector 的插件，但我对查看 GUI 中的差异不感兴趣，我只想要一种自动化的方式来比较二进制文件的集合，看看它们是否是从相同（或等效）的源文件。我知道多个不同的源文件可以生成相同的 IL，并且意识到该过程只会对 IL 中的差异敏感，而不是原始源。

仅比较两个程序集的字节流的主要障碍是 .NET 在程序集中包含一个名为“MVID”（模块版本标识符）的字段。这似乎对每次编译都有不同的值，所以如果你构建相同的代码两次，程序集会有所不同。

一个相关的问题是，有谁知道如何强制每个编译的 MVID 相同？这将避免我们需要一个对 MVID 值差异不敏感的比较过程。一致的 MVID 更可取，因为这意味着可以使用标准校验和。

这背后的背景是，在我们被允许发布到生产环境之前，第三方公司负责独立审查和签署我们的发布。这包括审查源代码。他们希望独立确认我们提供给他们的源代码与我们之前构建、测试和当前计划部署的二进制文件相匹配。我们正在寻找一种流程，使他们能够从我们提供给他们的源代码独立构建系统，并将校验和与我们测试过的二进制文件的校验和进行比较。

顺便提一句。请注意，我们正在使用持续集成、自动构建、源代码控制等。该问题与内部缺乏对特定构建中的源文件的控制无关。问题是第三方负责验证我们提供给他们的源是否产生了我们已经测试并计划投入生产的相同二进制文件。他们不应该信任我们的任何内部系统或控制，包括构建服务器或源代码控制系统。他们所关心的只是获取与构建相关联的源，自己执行构建，并验证输出是否与我们所说的部署相匹配。

比较解决方案的运行速度并不是特别重要。

谢谢

我需要比较使用相同编译器/标志编译的 2 个可执行文件和/或共享对象，并验证它们是否没有更改。我们在受监管的环境中工作，因此对于测试目的而言，准确隔离可执行文件的哪些部分已更改非常有用。

由于包含文件信息的标题，使用 MD5Sums/Hashes 不起作用。

有谁知道一个程序或方法来验证两个文件在执行上是否相同，即使它们是在不同时间构建的？

我有 4 个字节的数据，需要一个 8 字节的数组来进行安全操作。我应该从 4 字节字节数组中生成这 8 个字节，这应该是可重现的。

我正在考虑使用精确字节数组并添加 4 个额外字节，并以已知序列中的初始数组的 AND、OR、XOR 填充它们。我不确定这是否是个好主意。我只需要这 4 个字节中的一个 8 字节数组，并且操作应该是可重现的（相同的 8 个字节与相同的给定 4 个字节）。请举一个C#的例子

嗨，我使用 ccarm 编译器在 WinXP 上为 VxWorks 开发 C/C++。我想在很久以前构建的已发布交付之上添加一个热修复。来源保存在 Clear Case 中，并且每次交付都贴上标签。因此可以访问某个交付的源代码。

为了确保与原始发布版本没有任何变化，我必须确保我可以再次构建相同的输出文件。

这是问题所在；我从 CC 服务器检索源代码并构建它们。然后我将输出文件与相应的发布输出进行比较（输出文件类型为 *.lad 文件 + 文件格式 elf32-littlearm）。而且差异很大（不是一些时间戳）。另一方面，我也比较了装配清单，它们也不同。

你知道什么会导致这种差异吗？在我看来，可能导致这种差异的项目列表 - 发布的输出是使用自动构建脚本在不同的 PC（再次是 WinXP）上构建的。新输出是在我的本地构建的，具有相同的编译器和设置。- 从存储库中检索错误的标签

有什么要补充的吗？

提前致谢

我们有一些共享程序集，每晚都会自动构建。当源代码没有更改时，我希望程序集二进制文件与以前的版本完全相同。

但是，程序集之间似乎存在细微差别。

我已经做了一些努力来确定两个构建之间的差异。我曾经ildasm生成一个 il 版本，并比较了生成的文本版本。唯一的区别（在 IL 中）是模块中的 MVID（随机 guid）。

一些谷歌搜索告诉我模块版本 ID 是由编译器生成的，因此可以确定构建源，即使其他一切都相同。

此 MVID 在相同代码的构建之间创建人工差异，并人工签入生成的程序集。

是否可以将 MVID 提供给 C# 编译器？

我回来尝试比较两个 .exe，这次做了一些更改。

• 在 Microsoft Visual Studio 2010 中构建项目
• 项目目标框架 = .NET Framework 3.5 客户端配置文件

我构建项目，dumpbin /rawdata在 .exe 上运行并输出到文本文件。接下来我重新构建项目并dumpbin /rawdata在新的 .exe 上运行并输出到新的文本文件。然后我对每一个进行 CRC 校验以确保它们是相同的（在构建之间不进行任何更改）。

我得到不同的 CRC 值。当我通过运行原始数据时，windiff我看到了该Raw Data #1部分的差异，我认为这是从项目的源代码生成的实际数据（如果我错了，请更正）。

有 3 个不同的领域Raw Data #1，其中之一包括 .pdb。

问题：

1. 有谁知道我可以在哪里关闭 VS 2010 中的调试信息（类似于Project Property Pages -> Config Properties -> Linker -> Debugging -> Generate Debug InfoVS 2005）
2. 是否有任何技巧可以找出 WINDIFF 中突出显示的差异实际存在于源代码中的位置？

谢谢你，扎伊

PS - 随时要求澄清，并再次感谢一吨。我已经搜索了一段时间，但收效甚微。很高兴我找到了这个资源。

编辑/更新 我的转变现在已经转向使用 ngen 编译代码以绕过 MSIL 以及在那里显示为差异的任何内容。其中一个区别是在这个领域：<PrivateImplementationDetails>{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}.Dictionary......我不能从另一个区别中的 ascii 做任何事情（我摆脱了 .pdb 信息）。

我想知道是否有办法查看/提取编译后的代码以供查看。

我已经尝试ngen display "App Name"并搜索WINDOWS/assembly但找不到任何相关的东西（而且，我也不知道 100% 我在寻找什么......）

谢谢你的时间，ZayJay

我正在使用构建脚本来编译几个 C# 项目。二进制输出被复制到结果文件夹，覆盖文件的先前版本，然后添加/提交到颠覆。

我注意到编译的二进制输出是不同的，即使源或环境根本没有变化。这怎么可能？对于相同的输入，二进制结果不应该完全相等吗？

我不是故意在任何地方使用任何类型的特殊时间戳，但是编译器（Microsoft，.NET 4.0 中包含的那个）是否可能自己添加时间戳？

我问的原因是我将输出提交给 subversion，并且由于我们的构建服务器的工作方式，签入的更改会触发重建，导致再次修改的二进制文件被循环签入。

到目前为止，我从 VS 编译了我的项目，现在我将编译过程移到了一个脚本中。vcbuild.exe为此，我使用命令行参数。我看到的是我的输出文件在字节上根本不相似。 我比较了 VS 和我的脚本中的命令行，它与最后一个逗号相同，所以我真的不明白为什么它如此不同。

与 VS 编译和vcbuild日志相同的命令行（为清楚起见添加了换行符）：

为了源代码的完整性，我需要看看是否有可能使 boost 1.50 二进制文件可重现，而对源代码的更改尽可能少。挑战是在不更改任何 .cpp 或 .hpp 文件的情况下做到这一点。

由于__ TIME __和__ DATE __宏出现在 boost 库 WAVE 和 SPIRIT 中，只需编译两次并进行 diff 即可显示失败。

我正在使用 g++ 4.1.1 进行编译。任何人都知道通过某种环境变量告诉预处理器取消定义或重新定义这些宏的方法吗？如果不是环境变量，那么一些 g++ 命令行选项？我想我可以编辑一些 .jam 文件来重新定义__ TIME __和__ DATE __，宏到???? 或者 gcc 所说的默认值是当这些无法解决时。

也许有一种方法可以强制预处理器无法解析当前日期和时间，我可以启用、构建然后禁用它？

任何有关此的想法将不胜感激。谢谢你。

编辑：对于那些一直关注这个的人，我认为我在最初的问题中犯了一个严重的错误。我现在发现，使用完全相同的 bjam 构建命令进行简单的背靠背构建会产生 .a 和 .so 文件，它们除了DATE和TIME宏之外完全不同。二进制十六进制差异显示 .so 文件中的大量差异。.a 文件似乎遵循相同值始终不同的模式（这很可能是TIME和DATE宏值），但 .so 文件甚至不在同一个球场。如果有人有这种心情，我会挑战你两次构建 boost 1.50，比较构建输出并尝试证明除了构建日期/时间的变化所构成的信息差异之外，没有显着差异。

编辑（续集！）：在进行了更多挖掘之后，我发现了似乎是某种不一致的名称修改。只构建 boost 文件系统，两次，背靠背，并检查两者之间的文件 path.o 之间的差异，我注意到了这一点：

nm of first path.o: 00000000 b _ZN57_GLOBAL__N_libs_filesystem_src_path.cpp_00000000_8F1C916311path_localeE 0000000c b _ZN57_GLOBAL__N_libs_filesystem_src_path.cpp_00000000_8F1C916312dot_dot_pathE 00000000 r _ZN57_GLOBAL__N_libs_filesystem_src_path.cpp_00000000_8F1C916316separator_stringE 00000004 b _ZN57_GLOBAL__N_libs_filesystem_src_path.cpp_00000000_8F1C916317codecvt_facet_ptrE 00000004 r _ZN57_GLOBAL__N_libs_filesystem_src_path.cpp_00000000_8F1C916326preferred_separator_stringE 00000008 b _ZN57_GLOBAL__N_libs_filesystem_src_path.cpp_00000000_8F1C91638dot_pathE

nm of second path.o: 00000000 b _ZN57_GLOBAL__N_libs_filesystem_src_path.cpp_00000000_EDDD474511path_localeE 0000000c b _ZN57_GLOBAL__N_libs_filesystem_src_path.cpp_00000000_EDDD474512dot_dot_pathE 00000000 r _ZN57_GLOBAL__N_libs_filesystem_src_path.cpp_00000000_EDDD474516separator_stringE 00000004 b _ZN57_GLOBAL__N_libs_filesystem_src_path.cpp_00000000_EDDD474517codecvt_facet_ptrE 00000004 r _ZN57_GLOBAL__N_libs_filesystem_src_path.cpp_00000000_EDDD474526preferred_separator_stringE 00000008 b _ZN57_GLOBAL__N_libs_filesystem_src_path.cpp_00000000_EDDD47458dot_pathE

我不认为我以前见过这种事情。为什么这些特定的局部变量定义会被 EDDD4745 而不是 8F1C9163 破坏？有什么想法吗？今天我的头已经炸了一次（被附近的南瓜灯解决了）。这个简直是恶毒。

编辑：v3）

不幸的是，我仍然在做。在这一点上，我处于 ​​ELF 文件规范级别，试图确定发生了什么变化。我现在只是在使用 boost 文件系统。我的 bjam 命令是

试图确定到底是什么导致了这些差异是一件苦差事。readelf 很有帮助，但只是在一定程度上。我在这里有两个 readelf 命令在两个版本的 boost filesystem.so 上的差异，它使用了相同的源代码。我对这些东西的了解还不够，无法确定是什么影响了这些变化，也许世界上有人。

（我不得不删减文件中的一些条目以适应帖子）。在大多数情况下，其中一些条目的行号似乎不同。什么可能会改变 ELF 文件中符号条目的顺序？

提供如下简单的源 .cs 文件，有没有办法使用 MSBuild（或至少使用 csc.exe）生成相同的 .dll，以便它们的二进制哈希匹配？

foo.cs

foo.bat

示例二进制差异报告位于https://dl.dropbox.com/u/65419748/CscBin.html

有谁知道这些差异是什么以及如何解决它们？