>>I have the feeling that all what rests is your idea of excluding the vcx even from the main exe and placing that table in the same map where the exe's and apps reside.
>
>That's the only think left to do I guess. Because, others have reported the same problem where the app is freezing when the class is being invoked in such a context. So, I guess if nobody found a workaround for that, it'd be better that I go directly to the external storage of those VCX in the directory of where the EXE are launched.
>
>What would be expected is the following:
>
>1. Remove the main class from the main EXE
>2. Recompile the main EXE
>3. Copy the main class VCX, VCT files to the production directory
>4. If that doesn't work, do the same for the sub EXE.
>5. If that doesn't work, go back to original mode and put everything into one big EXE
>
>Point 5 seems to be overkill but it'd be faster (technically it should) at run time as only one EXE would apply. However, the update of each and everyone one of the client application (which would then be part of the main EXE) would require an upload of the entire application each time with the unload/load update process from WWC. I don't like this approach for maintenance purpose as it limits the flexibility we have to work on a small EXE for a specific client and having one developer to be responsible of one EXE and not another.
>
>This seems to be flinstone age but the only way I could see right now to an attempt to bypass that bug. But, I have the feeling we'll run into the same situation.
>
>As for performance issue, I guess once the EXE has invoked that class once, that it'd be as fast as if from the actual implementation.

Your plan sounds okay and I expect performance to be the same. I think that steps 1 and 2 may eventually be skipped until the main exe really needs an update. Good luck!