问题
I've one little question. In many software architectures, for example multi tier or something like the enterprise library, I expand some code in external assemblies. Sometimes my project includes more then 20 assemblies per solution. Now I'm confused... Are 20 assemblies to much? If yes, what I can do in a large project with different "sections" of logic? If i implement the enterprise library, I normaly have 5 assemblies minimally.
回答1:
Twenty assemblies is a long, long way from a problem. Just for comparison, when I look at Visual Studio right now, I see it having 249 assemblies loaded. Nothing particularly troublesome about VS on my machine, it does not use a lot of memory (283 MB right now) and starts up in a second or two.
The CLR does not spend heavy resources keeping track of assemblies in general. The only possible disadvantage of having a lot of them is that it can affect the cold-start of your program. And if your program initialization is not well optimized (VS was heavily optimized) and if you need to run from a slow spindle drive then those 20 assemblies can cost you a second worth of foot tapping. Only matters on interactive programs of course. ILMerge would be a workaround.
来源：https://stackoverflow.com/questions/28174973/are-to-many-assemblies-bad