Let’s say you have two products A and B which are both developed, tested and released at the same time by the same company. In the interests of code reuse and not doing the work twice, a third source control branch, C, gets created where low-level utility/framework/helper code is placed. This code includes some COM dlls.
Then the management decides that A and B should really have their own release cycles and be managed as completely separate products. Now you can’t modify/update C anytime you want because when one team is working on A, another team could be 2 weeks from releasing B so any code going into B (that also includes C) needs to be frozen.
The solution I see is to take C out and make it a stand alone SDK which both A and B would depend on. This SDK would have it’s own versioning scheme and its own release cycle. This way A could commit to using C-1.2.4 and if B needs something newer it can make changes in C-1.3.8
The problem I’m trying to solve now is how to handle COM DLLs given that it could be possible that both A and B could be installed on the same machine. I see three options but not sure which one is good/better or if there’s even another option I’m not seeing:
- Every time version number changes, have some kind of script go through .IDL files and change all coclass GUIDs. Might work but for some reason seems scary to many people (myself included)
- Use registry-free COM activation. Would this work with executables not under our control? (graphedt.exe, iexplore.exe…).
- Make sure all COM objects going forward are backwards compatible and have both A and B use the latest version of the modules which are installed. This seems like testing nightmare because we’ll end up with machines and DLL combinations that haven’t been QA’ed.
It’s been a while since I looked after a build or a release but I remember DLL HELL only to well! You have my sympathies!
As you’ve alluded to create an common installation – install it to C:\Program Files\Common Files\YourProductOrCompany\Version and register them. you’ll need to keep backwards compatibility and version your msi (assuming you deploy with that) correctly. That way each installation can install the common package if it has a greater version.
This worked well for us (around 8 products used a common core) but we had a comprehensive set of automated regression tests, so each time something was changed we could easily rerun the tests against the products.
And there came points where the changes were considered to great and the common component version was changed (including all the ClassIDs etc..). So you could have 10.1 and 11.1 running on the same machine using different cores.
HTH,
Matt