Breaking up - hard to do, but could be done - however...

Tech-Archive recommends: Speed Up your PC by fixing your registry

If forced to it, we probably would do just that. For now, my employer has
machines that can still do the compilation. (The buzz-kill for me is not
being able to do work at home without some scheme of somehow working with a
subset of the code; or finding another PC.)

The appeal of keeping it one huge executable rather than a collection of
ActiveX DLLs is two-fold:

- For easier customer service: Bug fixes can often be resolved with a
single new executable, which ZIPs down to a very managable size of under 900
KB. A self-extracting ZIP is far easier to make than making yet another
install package with InstallShield (which we use to make our web and CD
distributions).

- The various ActiveX and standard DLLs that are part of our app are
ActiveReports (which only once required an upgrade) and "standard" Microsoft
packages (such as MDAC, JET, Common Controls/Dialogs, etc.). Adding our own
set of ActiveX DLLs to that roster means more code management (GUID, class
names, type libraries, and the sub-projects to make them), and the potential
of COM or Registry issues of our own making - in addition to the ones we
already encounter.

But your suggestion has merit and obviously lots of folks are doing just
that. If forced to it then (*sigh*) I will too. I'm just dreading all the
code analysis and rewriting to accomodate ActiveX idiosyncrasies.

"*** Grier" wrote:

> Why not do what most people consider to be good practice? Create several
> projects that create dlls associated with the natural boundaries of your
> program? Then you may compile them separately, or as a group.

.

Quantcast