在 C# / .NET 中运行应用程序之前检查 DLL 是否真实/正确
您好，我正在尝试弄清楚如何确保提供的 DLL 是正确的。 原因是我们的分布式解决方案是由许多小型 DLL 构建的，每个 DLL 都包含应用程序的某些部分，有时我们会推出其中一些的新版本。
这不是“更新问题”，而是简单 - 我们如何检查是否：
其正确的二进制/汇编
客户/客户端是否已篡改该文件，并可能将其替换为具有类似功能的同名文件之一以返回错误值？
多种原因
这可以用于版权保护/许可证测试或其他重要的验证问题，所以我试图弄清楚MD5校验和+某种汇编信息是否足够？ （如果是这样，如何访问程序集详细信息或类似信息？）
当然，当您可以反编译 .NET DLL 时，没有什么是万无一失的，但正是因此，我们希望确保有人不只是反编译我们的函数列表，然后写入自己的替换 DLL我们的“哦，太重要了”DLL。
我们的原因是当我们遇到因错误或目的而毁坏这些的客户时，调试/支持所需的麻烦量（我们不关心原因，我们只是尽力防止大多数可能的错误）。
Hi I am trying to figure out how to make sure that a supplied DLL is the correct one.
Reason is that our distributed solution is build of many small DLL's each containing certain portions of application and sometimes we roll out a new version of some of these.
Its not a "update problem", but merly - how do we check if:
its the correct binary/assemble
the customer/client had tampered with the file and perhaps replaced it with one of the same name with similar functions to return bad values?
Multiple reasons
This could be used for copyprotection/licens test or other important validation issues, so I'm trying to figure out if MD5 checksum + some sort of assemble info is enough? (if so, how to gain access to assembly details or similar?)
Ofcause nothing is failsafe, when you CAN decompile .NET DLL's, but exactly therefore we want to make sure that someone doesnt just decompile our functionlist and then writes there own replacement DLL of our "oooh so important" DLL's.
Our reason is the amount of trouble debugging/supporting needed, when we get customers who have destoryed these by error or purpose (we dont care about the reason, we just try to prevent most of the possible errors).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我看到两个选项：
数字签名。您需要购买数字证书，但是一旦您使其发挥作用，您就可以对文件的来源非常有信心。还有一个优点是，您的程序不会在 Windows Vista 及更高版本中被标记为来自“未知发布者”。
哈希。您可以使用 MD5（或更好的 SHA-1）哈希值。非常容易实现，但可以解决保护问题（尽管这样做并不简单）。
I see two options:
Digital signing. You need to buy a digital certificate, but once you make it work you can feel very confident about the origin of the file. If also has the advantage that your programs won't be marked as being from "an unknown publisher" in Windows Vista and higher.
Hashing. You could use a MD5 (or better a SHA-1) hash. Very easy to implement but is possible workaround the protection (although it's not trivial doing that).
在 Visual Studio 中，您可以将引用指向库的“特定版本”。您只需在引用的属性中将默认的“False”更改为“True”即可。这将为您处理程序集信息的查找。使用绑定重定向覆盖它很简单，但这会阻止程序在意外安装错误版本的情况下尝试运行。
正如 @Alberto Martinez 提到的，我确实建议进行数字签名，以获得针对故意篡改的最佳保护。
In Visual Studio, you can point a reference to a "specific version" of a library. You just change the default 'False' to 'True' in the reference's properties. This would handle the looking up of assembly info for you. It's trivial to override that using a binding redirect, but this would prevent the program trying to run in situations where the wrong version is installed accidentally.
I do recommend digital signing to get the best protection against deliberate tampering, as @Alberto Martinez mentioned.