We have several shared libraries (C #, but I assume that it does not depend on the platform or language), call them A, B and C. Library A has links to B and C, library B has a link to a third-party DLL, and C library stands alone. The idea of three separate projects was that each library had excellent functionality, but Library A over time became a more or less “common” shared library, which is accessed by most references to client applications. Only a few applications link to B and / or C without A.
We are trying to improve our versioning conventions, and one thing we are trying to do is mark and release these DLLs correctly, so client project files can point to a static version of the code, changing the trunk. This turns out to be a bit confusing - for example, a client project that refers to both A and B. It itself refers to B, so there are technical links to B coming from the client project.
Thus, it is obvious that you just need to combine everything into a single shared / useful library with well-organized namespaces. As I said, almost every client application references one of these libraries, so who cares? This will not lead to undesirable situations with third-party dependencies, and all our target machines are internal and support approximately the same environment / software configuration.
This seems like too easy a solution, so I decided that at least I would get a second opinion. An alternative would be to use the GAC and a strict designation / version. Did I miss any catches here?
source
share