We’ve got a few common libraries (C# but I guess this isn’t platform- or language-specific), let’s call them A, B, and C. Library A has references to B and C, library B has a reference to a 3rd-party DLL, and library C stands alone. The idea behind three separate projects was that each library had distinct functionality, but library A has over time become a more or less “catch-all” common library that most every client app references. Only a few apps reference B and/or C without A as well.
We’re trying to improve our source control conventions, and one thing we’re trying to do is properly tag and release these library DLLs, so client project files can point to a static version of the code instead of the always-changing trunk. This is proving a bit convoluted – for example, a client project that references both A and B. A itself references B, so there are technically two references to B coming from the client project.
So the obvious thing seems to be to just combine everything into a single common/utility library with well-organized namespaces. As I said, almost every client app references one of these libraries, so who cares? Doing this won’t introduce any undesirable situations with 3rd-party dependencies, and all our target machines are internal and maintain roughly the same environment/software configuration.
This seems too easy of a solution though, so I figured I’d at least get a second opinion. An alternative could be to use the GAC and strongly sign/version everything. Am I missing any catches here?
I think you’re right consolidating into a single library.
Very often code is componentized into too many deployable units whereas the logical piece of functionality seems to be the criteria for separation. This is wrong IMO. Assemblies should be aligned with the deployment scenarios and release cycles instead. Otherwise you end up with a horribly complex dependency graph where anyways every assembly is managed, built and deployed together.
Interesting question though! Let’s see what other people think 🙂