Most of us who work on larger systems have probably developed, or worked on a project subsystem that contains core functionality that is shared across multiple solutions. Perhaps you have a utility library for user security, or a library of extension methods that make your development life easier. A project I am currently working on has one of these shared utility libraries. We use a common library in multiple projects and the way we share it is by linking the actual source repositories across projects and including the project files within multiple solution files.
Well today it occurred to me that this might be a bad idea. While it certainly makes the developer’s life easier, I think it can open you to more trouble than you gain from the convenience. I would like to make the case that that utility should be its own CI project that is maintained independently from its consuming solutions. If you need additional functionality, you should have to go make your changes, push through a “production” build process, then update your references to a compiled DLL.
This strategy will ensure that changes in the library for one dependency don’t have unforeseen consequences in another dependency.
Discuss!
Agreed. This makes active development on more than one project difficult. The "Utility" library will get many changes in it. If it's a breaking change, then *all* projects that use it must be updated as well, or worse, ignored and then broken until that project is picked back up again. It also discourages refactoring. There are a million reasons why I think this approach is wrong.
ReplyDelete