>1. Include class libraries in compiled .EXE
>
> Advantages: - we can pack .VCXs any time
> - safer, changes made in a class will not break existing
> applications (I believe this is what Jim suggested)
>
> Disadvantages: - changes made in a class are not visible to users until
> we recompile the .EXEs - about 100 in the system. And,
> to pick up the new version users will need to go out
> and then back in the system
> - bigger size for .EXE
>

This is largely a spurious disadvantage - regardless of what mechanism you use, the changes are not visible until you publish them, either in a new executable or in an external library that the executable can find. The primary advantage here from my POV is that it's easier to design and implement a launcher that can check the version of the executable on the local system and compare it to the most current 'live' version posted to the shared repository located on a server. It's also harder to 'forget' to include something needed by the app, or to have someone grunge up a support module; the code is contained in the app, so someone wandering through the cow pasture with a copy of Word won't break every program that references the component; the most they could od is mangle the executable.

Bigger size for the .EXE also means fewer files to maintain, and since there's going to be slack space for each file, the size of the 'fat' executable is probably less than the amount of space used by the 'executable on a diet' with a whole host of supporting files.

>2. Exclude class libraries from compiled .EXE
>
> Advantages: - changes made in a class are "live" - no need to
> recompile the .EXEs

In some cases, but you have to recompile the VCXs IAC (the p-code is in the VCX) and you don't dodge the bullet if the interface changes and you have to change other things as a result. Recompiling the EXE is not a big deal, and using a launcher to check the common repository and copy in a new version when it's detected eases the problems; since the .EXE in the repository is never run in the repository, only from a local copy, you can drop in the new .EXE and as people fire up the app via the launcher, the new version will trickle out.

> - smaller size for .EXE
>

But more little files, and probably uses more total space.

> Disadvantages: - we can NOT pack .VCXs unless ask all users out - there can
> be 50 users in at any given time.
>

Again, using a launcher, you can copy in newer versions of a VCX in the same manner as a new executable.