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

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 2

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 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.

Answer 4

For the situation were a library is reused by multiple independent solutions, or when the library is managed by another team than the team who uses it, I think the most important rule to keep in mind is that a particular version of a solution should normally be related to a specific version of that library.

Ask yourself the following: which version of the library do I get when I checkout the source code of the solution from six months ago? If the answer is: “Always the newest version of the library”, this could be problematic.

I worked on a project where the developers automatically published new versions of their dlls on the local network. The solution we were working on just referenced the dlls from that particular location. The problem with this was that we never knew to which version of the library we were compiling against and more than once, after testing, we released a version of our application that broke because suddenly a new version of that library was released (that we didn’t test).

But it will get even more obvious when you’re developing a version 2 of your application, but still have to maintain a released version 1 of your application. You want to release patches of version 1 with the same library version it was initially released with (when the bug is not in that library) because otherwise you will have to retest the whole application again.

Because of this I normally add all the libraries I use (that are not in the GAC by default) as part of my solution and check them in into source control. This way I have full control over the versions the solution uses at any given moment in time.