如何验证两个程序集之间的引用？答案

【问题标题】：How to validate references between two assemblies?如何验证两个程序集之间的引用？
【发布时间】：2019-11-21 15:47:17
【问题描述】：

AssemblyA.dll 指的是 AssemblyB.dll

AssemblyB 是用新代码重建的，而不是 AssemblyA。因此，我们不再确定 AssemblyA 是否兼容。也许它会在运行时崩溃，因为某些方法或属性被删除了。

从理论上讲，是否可以验证 AssemblyA 是否与 AssemblyB 兼容，而无需实际重建它？

【问题讨论】：

在开发 .NET 时，我们不得不处理您所描述的问题（亲切地称为 DLL Hell：en.wikipedia.org/wiki/DLL_Hell）。 Afaik，.NET 具有避免这种情况的设计属性。 |对于明确的参考，包括版本和证书。
这不是一件简单的事情。查看stackoverflow.com/questions/199823/… 以获取一些讨论和链接。要考虑的一件事是管理与文件版本控制不同的程序集版本控制（这将完全破坏兼容性）（遵循标准语义版本控制规则更有意义）。诀窍是查看您的用例（您更改的频率、谁使用您的程序集等），阅读各种可能的系统，然后提出符合您要求的东西 - 然后坚持下去。跨度>
静态 MSIL 代码分析可能会有所帮助，基于 Mono Cecil 等库，但同样，重建是最快的方法。
我正在考虑单声道塞西尔。我只是不确定是否很容易使我的验证详尽无遗。我可以轻松验证所有方法签名。还有其他需要考虑的吗？

标签： c# reflection reference .net-assembly

【解决方案1】：

您描述的场景称为DLL Hell。 Wich 只是 Dependency Hell 的 Windows 特定子集。在 .NET 之前（以及在它之外），它很常见。它基本上仅通过名称和路径来识别 DLL。

.NET 开发人员知道这一点并尝试了他们的damndest to avoid it。 .NET 不仅会通过名称识别引用的 DLL。它将至少使用名称、版本和证书。

两个 dll 可以具有相同的名称。只要它们的版本不同，.NET 就可以让它们分开。 .NET 甚至没有将它们同时保存在内存中的问题。您不只是针对“System.DLL”进行构建。您构建了“System.DLL。版本 Y，Zerficate X”。

【讨论】：

我的问题是我使用版本控制“最小版本，包括在内”，以避免因为单个 dll 已更改而不得不重建所有项目。我节省了很多编译时间。但是，我无法确保代码确实有效。我想我可以编写一个使用反射来实现这一点的验证器。但我想知道是否有一个工具可以为我做到这一点。分析 dll 会比重建快得多。
@UtilitaireCCV：版本控制意味着错误的（新）DLL 不会被意外加载或使用。运行时存在的正确（旧）DLL 完全是一个单独的问题。如有疑问，.NET 运行时只会告诉您“缺少 DLL Y，版本 X。请修复它，我不能那样运行这个程序。”
我使用“最低版本，包含”正是因为我需要一直使用最新的 dll。因此，在任何可能的情况下，我都不会面对这种“缺少版本 X”，因为代码接受任何版本，这就是重点，始终自动接受任何 dll 的新版本。我明白这也是我另一个问题的根源。
我明白你的意思。这是否意味着完全不使用“最小版本，包括在内”，或“完全匹配”以外的任何其他版本范围？从我们不能相信我们的开发人员避免意外引入重大更改的角度来看，我看不出我还有什么解决方案。
@UtilitaireCCV。每种高级语言中大约 90% 的唯一目的是让您无法相信其他程序员不会引入错误：私有/保护、只读、类型安全和泛型、输出变量、不可为空的引用。所有这些都在那里，所以其他人使用你的代码不会搞砸。 |您可以适当地计算出对两只手有性能或程序流程影响的关键字。