我们正在经历一个大规模的迁移项目,并试图验证部署到现场的代码是否与我们在源代码控制中的代码相匹配。
显然 .net 代码很容易比较,因为我们可以反汇编。由于编译方式,我不相信这在 vb6 exes 中是可能的。
有没有人对我如何验证源代码和编译的可执行文件与我在 Live 中的文件匹配有任何想法。
谢谢
Visual Basic 有(有)两种编译方式,一种是编译器(称为 P 代码),它会生成更小的二进制文件,另一种是生成“常规”windows .exe 文件(称为本机),因为它被引入应该比 p 码快;尽管使用此选项会增加编译文件的大小。如果您的编译使用 p 代码,理论上可以恢复源代码。
无论哪种方式都很难做到,但有些工具声称他们可以部分做到这一点,我知道的一个(从未尝试过,但有试用版)是 VB-decompiler http://www.vb-decompiler.org /
不幸的是,这几乎是不可能的。请记住,在不同机器上编译的 VB6 代码会有不同的 exe 大小和部署要求。
这就是为什么老 VB'ers 有一台专门的机器来编译他们的代码。
这不会帮助您处理已经部署的项目,但是如果您在每次编译时都增加了修订号(有一个项目设置可以自动为您执行此操作),那么您可以轻松比较版本号。
我的旧公司购买了该 VB-Decompiler 的副本,并且如前所述 VB5/6 生成额外的 P-Code,该工具确实生成了一些代码,如果不是可以“读取”的汇编代码。
如果您拥有编译的所有代码,您可以将该代码的 CRC 与现场部署的内容进行比较。但是,如果您没有原始编译代码,则取决于您如何编译代码(如果您使用 P 代码而不是本机代码,您可能能够反汇编,但反汇编看起来与您的源代码完全不同)。我怀疑您是否会将 PDB 与 exe 一起发布,但如果您这样做了,您当然可以使用它们与您的存储库中的源代码进行比较。
拥有一台可以检查您制作的各种库和 exe 并自动编译它们的受信任的计算机。将它们保存在只读但可访问的位置。然后在部署的站点和您的比较站点之间进行二进制比较。
但是,我不确定拆卸已编译单元的逻辑。我的公司和我所知道的大多数其他地方都使用构建计算机和单元测试的组合。在我们公司,我们制作的 EXE 是一堆库中的一个非常薄的外壳。例如,按钮单击将传递给执行实际处理的 UI Active X DLL。我们在构建之后要做的是运行一个特殊的 EXE 来执行我们的单元测试列表。如果他们都通过了,我们就知道我们的库(我们 90% 的代码所在的位置)是好的。至于实际的EXE,我们有一个大约需要两个小时才能完成的手动程序,然后我们就很好了。I在EXE中很少发生任何错误。