The separating of assemblies does help the development process, by splitting the assemblies by discipline or by AutoCAD .NET, MSSQL and others. Update only the changed assembly to all users.
Please re-read what I said. While it may simplify deployment,
that isn't the main advantage or purpose.
The main advantage is that you don't load code that will never
be used, or only be used occasionally.
Back to my original question. I have attempted refactoring and ended up
endlessly moving namespaces, classes, methods depending on:
- Discipline
- AutoCAD Entity/Object changing adding
- Database code
I am asking for advice on sitations I might face. I don't want to
end up next year with a 10MB assembly in AutoCAD, I would like
to start looking at any refactoring now.
Well, I would never build a single assembly that serves multiple
disciplines, especially if some of them do not use any of the
code that others use, which seems to be the case here.
Generally, I structure my assemblies in the same fashion that
I structure my code. For example, I have many classes that
I use in most of my applications. They go in an assembly that
I can then reference in each application that needs the code
(which in some cases, is almost every app I write).
Depending on the app and how extensive it is, I may build a
single assembly for the app (and reference common/reusable
library code from them), or I may build multiple assemblies for
the app, where each contains certain functionality.
For example, I have apps that make use of UI controls that
I've written, and I have other apps that have hardly no UI
at all. So, I put the UI controls in their own assembly, and
reference them from any assemby that needs them. In some
cases, there can be 4 or 5 assemblies with some that are
dependent on others, and dependencies that may go 2 or 3
levels down.
It ultimately depends on how much reusable code you have,
and from your description, it seems that you may not have
very much, which would also explain why you have a 0.7 MB
assembly.