我如何知道“程序集”是否已存在？真的改变了吗？
我在 VS2005 中创建了一个简单的“Hello World”应用程序。这是一个简单的控制台应用程序；它只包含以下行：
Console.WriteLine("Hello World");
Console.ReadLine();
当我尝试重建相同的控制台应用程序而不执行任何更改（只需按重建按钮）时，我得到了一个略有不同的可执行文件。 （我从第一个和第二个生成的可执行文件生成了 SHA-1 哈希，它是不同的！）
为什么在没有代码更改的情况下会不同？到底改变了什么？我使用十六进制编辑器进行比较，只看到几个不同的字节。
我想我的最终问题是，我怎么知道“程序集”是否真的发生了变化？ （当然，无需查看文件版本、文件大小等）
编辑
到目前为止，我们已经确定差异在于 PE 标头（时间戳和一些调试数据）。在我重新发明轮子之前，是否有一个忽略PE头的“程序集比较”工具？
谢谢， 伊恩
I created a simple "Hello World" application in VS2005. It's a straight-forward console application; it only contains the following lines:
Console.WriteLine("Hello World");
Console.ReadLine();
When I tried to rebuild the same console application WITHOUT performing any changes (just press the rebuild button), I get a subtly different executable. (I generated a SHA-1 hash from both the 1st and 2nd generated executable, and it's different!)
Why is it different when there are no code changes? What actually changed? I used a hex editor to compare and only saw a couple different bytes.
I guess my ultimate question is, how can I know if an "assembly" really did change? (Of course without looking at File versions, file size, etc)
EDIT
So far, we've established that the difference lies in the PE header (timestamp and some debug data). Before I re-invent the wheel, is there an "assembly comparison" tool that ignores the PE header?
Thanks,
Ian
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
差异将是
）（可能还有其他内容，根据您发布的其他输出？）要查看这些内容，请运行 dumpbin /all /rawdata： VS 命令提示符中的两个程序集上都没有。
要正确执行此操作，您必须编写一个比较工具来理解这一点并忽略这些字节，或者获取可执行文件的副本，清除时间戳和 GUID，然后比较这些版本。或者，在紧要关头，您可以按照 controlfreak 的建议使用类似
fc /b的内容，并假设如果存在fc /b。 20 个字节不同（4 个字节用于时间戳，16 个字节用于 GUID），那么它可能是相同的。您很可能会使用清除了时间戳的程序集 - AFAIK，如果您将其连接起来，它仅用于缓存其他 DLL 中导出的符号偏移量 - 但保持原样可能更安全。如果您确实需要二进制相同的程序集，我建议您更改流程，这样除非您确实需要它，否则永远不要进行干净构建。
The differences will be
(and maybe something more, as per the other output you've posted?) To see these, run
dumpbin /all /rawdata:noneon both assemblies in a VS command prompt.To do this properly you'd have to write a comparison tool that understood this and ignored those bytes - or took copies of the executables, cleared the timestamp and GUID and then compared those versions. Or, at a pinch, you could use something like
fc /bas controlfreak suggests and assume that if there are < 20 bytes different (4 for the timestamp, 16 for the GUID) then it's probably the same.You may well get away with using an assembly with the timestamp cleared - AFAIK it's only used to cache exported symbol offsets in other DLLs if you hook that up - but it's probably safer to leave as is. If you actually need binary-identical assemblies I suggest you change your processes so you never clean-build unless you really need it.
从 Visual Studio 命令提示符中，您可以进行更详细的比较：
您可以使用
dumpbin的输出来比较 PE 标头：或者您可以使用
ildasm< 来比较 PE 头和嵌入在程序集中的 IL 代码/代码>：/ALL选项将转储 DOS 和 PE 标头、CLR 标头、程序集元数据和反汇编 IL。但是，它不会包含嵌入资源。如果您的程序集包含嵌入式资源，您可以使用/OUT选项。这将为每个嵌入资源创建一个单独的文件，您可以使用您最喜欢的比较工具（例如 WinMerge）进行比较：From a Visual Studio command prompt you can do a more elaborate comparison:
You could compare the PE header using the output of
dumpbin:Or you could compare PE headers and the IL code embedded in the assembly using
ildasm:The
/ALLoption will dump the DOS and PE headers, the CLR header, assembly metadata and disassembled IL. However, it will not contain embedded resources. If your assmembly contains embedded resources you can use the/OUToption. This will create a separate file for each embedded resource that you can the compare using your favourite diff tool, e.g. WinMerge:在命令行上
fc /b <旧文件> <新文件>
On the command line
fc /b < oldfile > < newfile >