We have a suite of applications on my project at work. There are a number of components which are shared among the different applications in the suite. Some components are shared via a DLL. Others are wrapped in COM components. And a few are exposed through an OCX. This is standard fare for legacy Visual C++ development. The tricky part comes during installation of any one of the given applications. How should you do a build which installs a common component? We have chosen a way that seems to trip up developers.A quick a dirty method for sharing components which do not change often is to just check in the binary release version of the component. That way, when an application that depends on that shared component needs to be installed, you just register the binary copy you have in source control. This makes the default case of a build easy. However there is some extra work when you fix bugs or add features to the shared component. You have to manually update the binary copy you stored for build purposes.
Another technique we use for code that we think will change often is to include the code in the project of the application that needs the shared code. Then the build can get the latest copy of the code every time. This does add some complexity to the project. And it adds some time when you are trying to do a full build. However you don’t need to know any tricks.
Here is the dilemma. When we perform maintenance year after year on our product suite, it seems the sharing of common components seems to break down during build time. Some developers say we just need to redo the build scripts. However I think this is a sort of design issue. Or maybe it is more of a configuration issue. How do you best store common components in your system for easy maintenance and install?
