【问题标题】:Why the .net dlls generated for the same code and same .net framework version are not binary identical?为什么为相同的代码和相同的 .net 框架版本生成的 .net dll 不是二进制相同的?
【发布时间】:2011-04-14 10:32:25
【问题描述】:

我有一个 C# 项目,当在不同的机器上编译时会生成二进制不相等的 dll。所以我的问题是为什么生成的 dll 不同?有什么方法可以在不同的机器上生成完全相同的 dll 吗?

编辑 这是我想要做的。有多个客户端机器从服务器获取一些代码 sn-p 并编译它。 dll 编译完成后,会在客户端反复使用。如果我可以在所有机器上生成相同的 DLL,那么我可以很容易地检查 DLL 在客户端使用加密哈希是否被篡改。

由于某些原因,代码必须在客户端计算机上编译。因此,数字签名不是一种选择。

【问题讨论】:

  • 为什么需要二进制相同的库?此外,如果了解所涉及的机器、操作系统、.NET 版本、使用的 IDE 或编译器的确切配置,也会很高兴。
  • 您是否在启用优化的情况下进行编译?为什么需要获取二进制等效的文件?你想解决什么问题?
  • 也许两个项目设置了不同的程序集信息?就像例如GUID。
  • 显然机器的配置或编译设置在某些方面有所不同。他们有什么不同? .net 程序集可以包含构建版本信息 - 这是唯一的区别吗?
  • @Steven Jeuris:不同之处在于文件的开头和结尾。此外,只有少量字节不同。

标签: c# .net dll compilation


【解决方案1】:

你不能期望任何重新创建的文件的二进制文件都是相同的——更不用说程序集了。所有文档元数据,包括创建的数据、修改的日期都会不同。

如果需要比较,需要对程序集进行签名(强命名),并比较公钥令牌加程序集版本。


更新

尽管我可以理解有时必须这样做,但您正在做的是自找麻烦。如果我是你,我会在服务器上编译二进制文件并让客户端下载二进制文件而不是代码。归根结底,客户的机器上可能没有 C# 编译器。

回答您的问题,如果您坚持在客户端编译,每次编译时,创建一个本地哈希并存储在注册表、某个文件等中,然后比较该哈希。


更新 2

C# 编译器从不保证它会创建相同的二进制文件。许多东西是在编译时创建的,例如命名匿名函数、自动属性的支持值、匿名方法、内部 GUID……所有这些都将在编译时创建,而编译器使用命名约定,名称通常以同样,不保证

【讨论】:

  • 是的,代码签名是合适的解决方案。机器的配置无关紧要。您必须使用正确的工具来解决手头的问题。
  • 我已更新问题并添加了有关该场景的详细信息。由于某些原因,代码必须在客户端机器上编译。因此,数字签名不是一种选择。
  • 我检查了它以确定,但至少对于 NTFS,时间戳元数据存储在 Master File Table 而不是文件中。当然编译器仍然可以存储一个额外的日期,但这对我来说似乎没用。
  • 是的,我真傻——我的意思是文档属性,例如媒体文件或办公文档中的那些。我会更新我的答案...
  • +1:我只是在比较一些二进制文件并注意到更新 2 中提到的行为。此外,在构建 Debug 版本时,我遇到了一些进一步的变化。
猜你喜欢
  • 1970-01-01
  • 2015-09-27
  • 1970-01-01
  • 1970-01-01
  • 2022-01-04
  • 1970-01-01
  • 1970-01-01
  • 2015-12-19
  • 1970-01-01
相关资源
最近更新 更多