Can I prevent VB6 OCX controls generating OCA registry entries on compilation?

3
votes

We have a project here written in VB6 (yes, I know...) which consumes some ActiveX objects also written in VB6 (OCX files).

Recently we started using a build server for this project and, with the help of the MSBuild Extension Pack we devised a build process which compiles the libraries, controls and executable all in the correct order, registers them as appropriate and then unregisters everything to leave a clean machine for the next run.

The problem is that each compilation run leaves entries in the registry for the extended type library/object cache files which the VB6 compiler appears to require, and these entries are not removed when the controls are unregistered.

i.e. for every registered component which has a CLSID entry pointing to the OCX, there exists, after we compile the project with VB6, a newly generated CLSID for the OCA.

Because we unregister the OCX controls after each build and the OCA CLSIDs are generated afresh each time, the number of OCA entries continues to grow.

Does anyone know what causes these entries, whether we can remove them through some kind of unregistration process or whether we can prevent them being created in the first place?

A few notes :

  • The build machine is Windows 7
  • Binary compatibility is enabled, so the CLSIDs of the OCX controls aren't changing.
  • Reg-Free COM isn't currently an option
  • We cannot simply register the controls and leave them as we want to run more than one build of this project.
1
windows-7comvb6activex
Due my lack of knowledge about msbuild Extension - what we had to do in the "normal" build process (although not from the ide, we had a batch Job) we had to provide the binary compatibility file for our controls and com dll´s. We never deregistered them, and we had a clean registry (ok, most of the time ...) - Thomas Krojer
That's what we're doing with our build server. Binary compatible files are part of the source repository and brought down with everything else. Unfortunately, deregistering them is essential if you want to move the location (in our case we have development, UAT and release configurations which compile to different output folders - it would be very bad indeed to be building the release against controls registered in the development output). - adhocgeek

1 Answers

-3
votes

The key is to stop trying to treat DLLs (including OCXs) like statically linked libraries. Your build process is inappropriate.

While VB6 supported a crude "project group" capability, this was only meant for small scale unstructured development efforts like those used by under-the-radar business unit coders.

Instead strive to keep application-centric logic within your EXE projects. Factor out longer-term reusable logic into DLL and OCX projects that you treat as separate, unique internal products. Maintain these (including source control) compeletely separately from consuming applications.

Normally these should be far more stable than application code where changes are driven more frequently by the business logic they contain.

Even when some of these must contain business logic, you still want to treat them as separate software entities. Try to keep them distinct from libraries that have more stability.

This requires more discipline than monolithic "tower of Bable" development but there are many rewards. Build time is quicker for one thing. And as a bonus almost all of these source control related issues disappear for the applications which have a much higher rate of tinkering and fiddling.