Separation of assemblies - search for balance (exclusion of overflow)

Question

I am writing an infrastructure with a wide component that will be used in my projects. Since not all projects require the creation of each component, I thought about dividing the component into discrete assemblies so that each application being developed was deployed only with the necessary assemblies.

I assume that creating the assembly has some overhead for storage (assembly code, all contents inside). Therefore, there must be some kind of restriction on the advantage obtained by splitting an assembly - a certain point where the separation of the assembly is worse than maintaining its integrity (in size and performance).

Now, here is the question: how do I know when assembly separation is redundant?

PS I think there are other assembly overheads other than storage costs. If someone can indicate this overhead, that would be very appreciated.

Answer 1

There are other overheads for splitting assemblies:

• More compilation time (the more projects you have in the solution, the longer it will take)
• Deployment nightmare - especially updates to core components.
• More builds may end up slowing down your applications

Why do you need to separate them? So that they are logically separated? If this is the case, use namespaces and do not split the assemblies.

Answer 2

Robert C Martin ( SOLID) , :

" ".

, , , , . , , . , ?

Answer 3

, . , . , , - A, B A. , , , .

Answer 4

Hm, , - "". . / (, y-), GAC Visual Studio, ).

, , . , "" . , , DAL.... , "intern" l .

In addition, if you switch more “formally”, different subsystems will have different owners / development cycles / program managers.