>I have a very large EXE (11mb) and would like to break it up so that I can work on one component without affecting others. In other words, I have 5 modules and would like them separate so I can do work on one and recompile my EXE without worrying about where I am on the other 4. Anyone know what I should do?
You can break them up into separate projects, especially if they do not share common components - simply create separate projects and compile them as separate apps/.EXEs as you see fit. A few caveats:
If the separate modules all explicitly reference common class libraries/forms/ procedure libraries and the like, they will occur in each piece that you create. Should the separate modulesevery get out of sync, there can be all sorts of confusion because different versions of the same thing run at the same time.
Referencing common pieces may require you to make explicit reference to the place they reside in order to have them found - NEWOBJECT in particular has caught me on this.
Things that convert from their Designer form to executable code that reside in more than one place must be rebuilt in all places when they are changed - menus are a good example of this.
If you create .EXE files for you modules, and not all can be a valid starting place, add code to check that something didn't accidentally launch the wrong first module.
DO and UDF references are probably the most easily misidentified blocks of code when using this approach. Be careful if multiple procedures/function copies live in the separate pieces.
If the app is being built on a custom basis for a single site, you could always have a project which included a minimal block of code, and exclude the remaining component pieces from the project, and leaving them as separate pieces - this would minimize the effects of making changes - individual modules that are not a part of the main .EXE can be added/deleted/updated without having to change the main executable. This is actually a fairly common approach - for example - Visual AccountMate excludes their screens and forms from their executables to make it easy for the end-user to customize their standard modules without having to open up the business logic for their application beyond offers general documentation on exposed interfaces for some of their classes. I do this where I may have some revisions to my application under test but only with some of the users.
