Is there a "max" number of assemblies for a .net app

Question

Quite a few apps support plugins

Are there any downsides to having a large # of plugins ? Is there a sweet spot beyond which there's a performance degradation perhaps ?

What's the largest # of assemblies you've seen loaded in an app ?

Answer 1

I do not have concrete info but am quite sure you can have more assemblies than you need before you see any degradation.

Having said that, it's subjective to several other factors like 'quality' of the assemblies, system resources etc etc.

Answer 2

No, there is no sweet spot. More code takes more time to load and JIT compile. But it isn't necessarily predictable when that occurs, it happens on demand. The max is only restricted by available virtual memory space on 32-bit machines, paging file size on x64 machines.

Answer 3

I'm not aware of any specific limitations on the number of assemblies. But having been faced with performance problems due to many assemblies, I can speak a little bit about that.

Because of the various consistency checks that the CLR performs when loading assemblies (strong name verification for example) and the likelihood that rebasing is required it's very possible that having a large number of assemblies could have significant performance implications.

But if your application doesn't require all of the assemblies to be loaded up front, having them broken out into multiple assemblies may actually help to defer the cost of loading assemblies over a longer span of time instead of loading one massive assembly up front.

Three things you could do to improve the load times if they become a problem are:

• Strong name your assemblies and put them in the GAC at install time
• Run NGEN on the GAC'd strong named assemblies at install time
• Specify a non-default base address for the various DLL's to minimize rebasing

For 1 and 2 they pretty much go hand in hand. NGEN performance gains might not be fully realized unless the assemblies are in the GAC because of the strong name verification. CLR can skip this verification for assemblies in the GAC.

Here's an excellent MSDN article regarding application startup times.

Answer 4

One visible limit is memory usage. Every modules will be loaded into memory. So for 32 bit OS you get 1.3GB, and for 64 bit OS the limit is too large to hit for today's applications.

Answer 5

I once worked on a backend-framework that had an assembly dependency tree of over 2500 endpoints. It was disgusting and took two hours to build.

So while you can load tons and tons of them, prepared to have people pointing at you and throwing things.

Answer 6

I don't think that using enabling plug-ins will lead you to assembly count problems. You would have a really killer application (like Firefox) to have that number of plug-ins, but event then an average user won't load all the available plug-ins.

Assembly number problems are more often caused by too much granulation in the project itself. I've seen monolithic application which consists of a 100 Visual Studio projects because architect said 'we need low coupling'. Try to adhere to Roy Osherove's rule: each assembly should have a physical (not logical) reason to exist. Logical problems are better solved by namespaces, not assemblies.

Hope that helps.