Working with Common/Utility Libraries

Question

At the company I work for we have a "Utility" project that is referenced by pretty much ever application we build. It's got lots of things like NullHelpers, ConfigSettingHelpers, Common ExtensionMethods etc.

The way we work is that when we want to make a new project, we get the latest version of the project from source control add it to the solution and then reference the project from any new projects that get added to the solution.

This has worked ok, however there have been a couple of instances where people have made "breaking changes" to the common project, which works for them, but doesn't work for others.

I've been thinking that rather than adding the common library as a project reference perhaps we should start developing the common library as a standalone dll and publish different versions and target a particular version for a particular project so that changes can be made without any risk to other projects using the common library.

Having said all that I'm interested to see how others reference or use their common libraries.

Answer 1

That's exactly what we're doing. We have a Utility project which has some non project specific usefull functions. We increase the version manually (minor), build the project in Release version, sign it and put it to a shared location.

People then use the specific version of the library.

If some usefull methods are implemented in some specific projects which could find their way into main Utility project, we put the to a special helper class in the project, and mark them as a possible Utility candidate (simple //TODO). At the end of the project, we review the candidates and if they stick, we move them to the main library.

Breaking changes are a no-no and we mark methods and classess as [Obsolete] if needed.

But, it doesn't really matter because we increase the version on every publish.

Hope this helps.

Answer 2

I've had the EXACT same issue!

I used to use project references, but it all seems to go bad, when as you say, you have many projects referencing it.

I now compile to a DLL, and set the CopyLocal property for the DLL reference to false after the first build (otherwise I find it can override sub projects and just become a mess).

I guess in theory it should probably be GAC'ed, but if its a problem that is changing a lot (as mine is) this can become problematic..

Answer 3

We use branching in source control; everyone uses the head branch until they make a release. When they branch the release, they'll branch the common utilities project as well.

Additionally, our utilities project has its own unit tests. That way, other teams can know if they would break the build for other teams.

Of course, we still have problems like you mention occasionally. But when one team checks in a change that breaks another team's build, it usually means the contract for that method/object has been broken somewhere. We look at these as opportunities to improve the design of the common utilities project... or at least to write more unit tests :/

Answer 4

@Ed: the problem I've found with the unit tests is that a few of the team members don't quite understand some of the finer concepts of unit testing so they'll change the unit test to suit their needs, so the code passes the unit test, but doesn't actually do what it was originally intended to do

Answer 5

@lomaxx: That would make it difficult :). Aside from telling people not to change unit tests they don't own (or putting each team's tests in their own fixture or project or something), I'm not sure how you could deal with that, other than just training people on unit testing. Easier said than done.