.NET应用程序是否有最大数量的程序集？
相当多的应用程序支持插件。
拥有大量插件有什么缺点吗？ 是否存在一个可能性能下降的最佳点？
您在应用中看到的最大assembly数量是多少？
我曾经在一个后端框架上工作，该框架具有超过2500个端点的汇编依赖树。 这真令人作呕，花了两个小时才建成。
因此，虽然你可以装载吨和吨，准备让人们指着你扔东西。
我没有具体的信息，但我确信在看到任何退化之前你可以拥有比你需要的更多的组件。
话虽如此，它对诸如组件的“质量”，系统资源等其他几个因素也是主观的。
不，没有甜蜜点。 更多代码需要更多时间来加载和JIT编译。 但是，当发生这种情况时，它不一定是可预测的，它是按需发生的。 max仅受32位计算机上可用虚拟内存空间的限制，x64计算机上的页面文件大小。
我不知道组件数量有任何具体限制。 但由于许多组件而面临性能问题，我可以谈一谈。
由于CLR在加载程序集时执行的各种一致性检查（例如强名称validation）以及需要重新定位的可能性，因此很可能拥有大量程序集会对性能产生重大影响。
但是，如果您的应用程序不需要预先加载所有组件，将它们分成多个组件实际上可能有助于延迟在较长时间内加载组件的成本，而不是预先加载一个大型组件。
如果它们成为问题，你可以采取三件事来改善加载时间：
- 强化您的程序集并在安装时将它们放入GAC
- 在安装时在GAC强名称程序集上运行NGEN
- 为各种DLL指定非默认基址以最小化变基
对于1和2他们几乎齐头并进。 由于强大的名称validation，除非程序集在GAC中，否则NGEN性能提升可能无法完全实现。 CLR可以跳过GAC中程序集的此validation。
这是一篇关于应用程序启动时间的优秀MSDN文章。
一个可见的限制是内存使用。 每个模块都将加载到内存中。 因此，对于32位操作系统，您获得1.3GB，而对于64位操作系统，限制太大，无法达到今天的应用程序。
我不认为使用启用插件会导致assembly计数问题。 你会有一个非常杀手级的应用程序（如Firefox）拥有这么多的插件，但事件然后普通用户将不会加载所有可用的插件。
assembly编号问题通常是由项目本身的过多粒度造成的。 我见过单片应用程序，它包含100个Visual Studio项目，因为架构师说’我们需要低耦合’。 尽量遵守Roy Osherove的规则：每个集会都应该有一个物理 （非逻辑）理由存在。 命名空间而不是程序集可以更好地解决逻辑问题。
希望有所帮助。