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