Here at work we have a very large application with multiple sub applications. (500 + dlls)
As a developer it is very frustrating working with all these dlls and dependencies. You create a new project and add 5+ dlls to get core pieces of the system to work (Logging, Auditing, security, messaging ect). Each new subapplication we add, we make a web project, a business layer, a data layer and any other projects needed to share objects between the 3, so our list just keeps expanding.
My question is what is the best way to manage this? i can't seem to think what is best.. the modular approach seems good for re-usablity, and hot patching items without taking down the system for one application. But the headache in managing 500 dlls is a nightmare.
Does each subsystem really need 3-4 projects, and reference the other 5 core pieces?
What are other ways of managing large projects keeping managing/developing and deploying in mind?
I have very good experience with naming guidelines in all types of projects (currently I working on 250+ dlls project). If you (or anyone else) choose good naming conventions, you see on first look what "it" is and you know how named is something you need.
Don't worry about count of references in project. If you are frustrated of adding X references every time, you can create a macro which will do it instead you. Or you can create a template VS solution/project/items(files) with your special requirements.
The large projects are large, so it's not surprise, if you must working with large amount of dlls, classes, etc...