.NET 应用程序的程序集数量是否有上限？答案

【问题标题】：Is there a maximum number of assemblies for a .NET app?.NET 应用程序的程序集数量是否有上限？
【发布时间】：2011-01-26 05:04:10
【问题描述】：

不少应用支持插件。

拥有大量插件有什么缺点吗？是否存在可能导致性能下降的最佳点？

您见过的应用程序中加载的最大程序集数量是多少？

【问题讨论】：

【解决方案1】：

我认为使用启用插件不会导致您遇到程序集计数问题。您将拥有一个真正的杀手级应用程序（如 Firefox）来拥有这么多插件，但如果普通用户不会加载所有可用的插件。

程序集数量问题通常是由项目本身的粒度过多引起的。我见过由 100 个 Visual Studio 项目组成的单体应用程序，因为架构师说“我们需要低耦合”。尽量遵守 Roy Osherove 的规则：每个程序集都应该有一个物理（非逻辑）存在的理由。逻辑问题最好通过命名空间而不是程序集来解决。

希望对您有所帮助。

【讨论】：

【解决方案2】：

我曾经研究过一个后端框架，它有一个包含超过 2500 个端点的程序集依赖树。太恶心了，花了两个小时来构建。

因此，虽然您可以装载大量的东西，但准备好让人们指着您并扔东西。

【讨论】：

【解决方案3】：

一个明显的限制是内存使用。每个模块都将被加载到内存中。因此，对于 32 位操作系统，您可以获得 1.3GB，而对于 64 位操作系统，这个限制对于当今的应用程序来说太大了。

【讨论】：

【解决方案4】：

我不知道对程序集数量有任何具体限制。但是由于许多程序集而面临性能问题，我可以谈谈这一点。

由于 CLR 在加载程序集时会执行各种一致性检查（例如强名称验证），并且可能需要 rebasing，因此拥有大量程序集很可能会对性能产生重大影响。

但是，如果您的应用程序不需要预先加载所有程序集，则将它们分解为多个程序集实际上可能有助于在更长的时间跨度内延迟加载程序集的成本，而不是加载一个庞大的程序集在前面。

如果出现问题，您可以采取以下三项措施来缩短加载时间：

对于 1 和 2，它们几乎是齐头并进的。由于强名称验证，除非程序集在 GAC 中，否则可能无法完全实现 NGEN 性能提升。对于 GAC 中的程序集，CLR 可以跳过此验证。

【讨论】：

根据这篇文章msdn.microsoft.com/en-us/magazine/cc163610.aspx 摘录，重新定基不是问题 - JIT 编译的代码没有变基问题，因为地址是在运行时根据代码在内存中的位置生成的。此外，MSIL 很少受到基地址未命中的影响，因为 MSIL 引用是基于令牌的，而不是基于地址的。因此，当使用 JIT 编译器时，系统对基地址冲突具有弹性。
是的，但我的重点是使用 NGEN 来避免 JIT。 NGEN 的代码确实受到变基的影响。实际上，JIT 完成了 rebase 所做的所有工作，甚至更多。因此，避免 JIT 是快速加载大量程序集的关键。
无论如何，我知道这是社区 wiki，但我认为我的回答没有任何理由证明投反对票是合理的（不是声称是你，只是说......）跨度>
抱歉，这是一个粗心的错误，因此除非您编辑答案，否则我无法更正它！
关心在你的答案中编辑一些东西，这样我就可以纠正错误的否决？

【解决方案5】：

不，没有甜蜜点。更多代码需要更多时间来加载和 JIT 编译。但它何时发生不一定是可预测的，它是按需发生的。最大值仅受 32 位机器上的可用虚拟内存空间、x64 机器上的分页文件大小限制。

【讨论】：

【解决方案6】：

我没有具体信息，但我很确定在你看到任何退化之前你可以拥有比你需要的更多的程序集。

话虽如此，它还受其他几个因素的影响，例如程序集的“质量”、系统资源等。

【讨论】：