【问题标题】:How to automatically detect and release DLLs that have really changed?如何自动检测并释放真正发生变化的DLL?
【发布时间】:2011-10-14 15:47:57
【问题描述】:

每当我们重新编译一个 exe 或一个 DLL 时,即使源代码相同,它的二进制映像也是不同的,这是由于映像中的各种时间戳和校验和。

但是,我们的质量体系意味着每次发布新的 DLL 时,都必须再次执行相关的验证测试(通常是手动的,并且需要大量时间。)

因此,我们的目标是避免发布没有实际更改的 DLL。即:拥有一个自动程序(脚本、工具等),仅根据它们包含的有意义的信息(代码和数据)检测不同的 Dll,忽略时间戳和校验和。

有什么好的方法可以实现吗?

【问题讨论】:

    标签: windows binary release compare


    【解决方案1】:

    以版本信息为基础,仅在实际进行更改时更新版本信息。

    【讨论】:

    【解决方案2】:

    让您的构建工具构建 DLL 两次。两者之间存在的任何差异都保证是时间戳或校验和的结果。现在您可以使用该信息与您的下一个版本进行比较。

    【讨论】:

    • 感谢您的回答。看起来像一个可能的解决方案,但我想知道它是否适合,实际上。可变部分的位置(和数量?)可能会根据不同的段大小(或不?)而改变。该解决方案还必须适用于许多 dll(我们有几十个),但是通过与连续但相同的构建进行比较,检测变量位置可能也可以自动完成一次。两个不同的时间戳也有机会生成相同的校验和......
    • 如果您有两个来自相同源文件的自动构建,则变量部分不应更改。是的,校验和可能有很小的机会相同......更可能的是校验和的单个字节是相同的。所以你会有很小的机会出现误报,这仍然比误报要好,而且比你今天的情况要好。
    【解决方案3】:

    如果您有一个在开始构建之前同步源代码的自动构建系统,那么只有在源代码控制中有任何实际更改时才继续构建和发布。您应该能够从源代码管理客户端的输出中轻松检测到这一点。

    【讨论】:

    • 是的,这只是我们之前所做的,但考虑到源代码控制(或 dll 版本)远非完美。源中的更改并不总是生成不同的 DLL。例如:更新(doxygen)cmets,在许多模块共享的头文件中添加函数,拆分头文件......无论如何这意味着太多的人为因素。对于一个职业选手来说可能还可以,但对于普通团队来说就很难了。
    【解决方案4】:

    我们的构建系统也有同样的问题。不幸的是,检测是否有任何实质性代码更改并非易事,因为我们有许多静态库,因此更改其中一个可能会导致 dll/exe 更改。更改 dll/exe 直接使用的文件可能只是修复错误注释,而不是更改生成的目标代码。

    我之前一直在寻找一种工具来满足您的需求,但没有找到。我的想法是手动比较这两个文件并跳过两个版本中无意义的差异。 Portable File Format 有据可查,所以我不认为这会非常困难。我们的额外要求要求我们忽略标记在 dll/exe 中的版本,因为我们对所有文件进行唯一标记,并且在我们签署所有可执行文件时也忽略签名。

    我还没有时间来做这些,但如果您继续实施解决方案,我很想与您合作。如果您确实找到了可以执行此操作的工具,请告诉我们。

    【讨论】:

    • 我目前正在探索一个涉及 DumpBin 的解决方案。它的功能之一是仅将可执行文件的数据(代码+资源)部分导出到文本文件中。 DUMPBIN /RAWDATA MyApp.EXE > MyApp.txt 见support.microsoft.com/kb/164151
    • 我没有考虑过使用 DumpBin,感谢您的提示。如果这行得通,它肯定会为我节省很多时间。
    猜你喜欢
    • 2011-01-30
    • 1970-01-01
    • 2016-12-28
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2011-03-17
    • 1970-01-01
    相关资源
    最近更新 更多