You can do this, but it is a PITA. Let me tell you about my experience with this. I went from one extreme to another. I provided all forms separately with the method code stripped from the files. Performance went to hell fast. When I included the forms back into the compiled APP/EXE, performance returned.

What has worked is providing 2 or 3 APP files. Each APP is represented by its own project. The downside is I have to include my classes in all projects. So I do not get one 20 MB split up into two 10MB APP files. You get two 11MB APP files, for example.

Your projects will probably pick up the other APPs so you will need to exclude them from each project.

I always exclude reports in my projects and provide them separately with no problems.

>Hi guys,
>
>I opened by big mouth in a meeting yesterday and said it would be possible to split up a monolith of an application (17MB exe) into smaller components. The idea was that as various bits of the application change, only the bits that have changed can be updated.
>
>Does anyone have suggestions on the best way to achieve this? I don't want to go all the way to shipping VCXs, SCXs etc compiled outside the app as this would mean too many files to ship. My hope was to be able to break the whole thing up into a dozen files each of 1MB or so.
>
>The app is fairly integrated, and is an 'old-fashioned' design with a main program, large utils program, global variables and forms called with DO FORM from a 'main form'. Classes are generally visible objects/containers dropped onto forms.
>
>Can anyone suggest a way forward? I am open to all ideas!
>
>TIA
>
>Les