In house reusable libraries - reuse as dll or as projects?

Question

We have quite a bit of reusable code at work (a good thing). Whenever I create a new project that use them I am used to include their projects as part of my solution, and I was wondering if I should instead reuse them as published dll's instead. The reason (or excuse) I include the project is that if I find a bug in one of them I can branch and fix that right there. But it seems to be taking my focus from the project at hand.

(Not sure if this should be CW since there are only two answers and I would be interested in learning about your preferences)

Answer 1

There's a few things to consider here.

• How much extra time do those libraries add to the compile, and do you care?
• How often do you need to fix bugs in them?

I use precompiled libraries for any code that doesn't change in months. If I need to change some code more than once a month in a package then that package isn't precompiled.

I prefer precompiling to speed up compilation of the main program. But I always include debug symbols in the precompile so if an error occurs I can step through the precompiled assembly just as easily as the rest.

Answer 2

That really depends if you are on the team responsible for them or not if you are on the team add them to your source and fix them as you go. If you are not on that team use them as a customer and file defects as you find them otherwise you may become responsible for code outside of your job scope. If you are in a flexible environment that may not matter but for me it could be a problem to all of a sudden be the owner of a code change I have no say over.

Answer 3

One consideration for this is just how frequently said libraries are reused. If they tend to be used across completely different projects, you have to be careful not to paint yourself into a corner, where you find out that changes you made three weeks ago to the library to support some new app turned out to be breaking changes for a few other applications.

Basically what I'm saying is that you don't want to have to resist the temptation to make changes to a library willy-nilly; better to not put that temptation in front of you in the first place. If a library is designed for reuse, any significant changes to it should be designed and implemented very carefully, and thoroughly tested against all dependent libraries/apps. It becomes considerably more difficult to take a disciplined approach when you literally have the source right in front of you, waiting to be modified.

My approach is to create solutions of related libraries; for example, I might have one assembly for the core interfaces and abstract classes, a few other assemblies for different concrete implementations, another for unit tests, and so on. If there are layers of dependent reusable libraries then they will often all get lumped into the same solution.

But it stops at the application level. Any project that's not always going to get deployed with the core libraries does not share a solution, it simply references the compiled DLL. It forces me to be disciplined about library changes and not start tweaking it in order to support some specific UI function.

I don't know if this is the "right" approach, but I have been bitten before by making premature changes to libraries without properly testing dependencies, and it's always been a result of being too focused on a single app and not thinking about side-effects. My take on this is that when you work on a library, you need to be focused on the library itself and not how it's being used in a particular scenario.