>We had an issue like this with a project I worked on a while back and that is what we ended up having to do. The problem with that is if the versions get out of synch - say, the primary app has been built with an older version of the class library than the secondary app - then the first one instantiated controls the behaviour of the objects from then on. It turned out to be a bigger PITA than simply including all of the source for the second into the first and having only one EXE.
>
>It might be worth your while to take a step back and think about what it is you are trying to accomplish. If you need a separate executable with different functions - only a subset as a utility for example - that can be run independantly of the first, then making another EXE makes sense. Otherwise you'd be better off with one EXE if you can. You could also make the classes non-visual (yeah, it's not my favorite way to work with them either, but you get used to it) which can be easily done for forms if you don't load tables in the data environment, but that may not be an option or more work than you want to deal with.
>
>Just a thought...


I hear what you're saying, and I might just have to resort to one EXE. The main reason I wanted to do this was so that when I'm working on new modules and utilities, I don't have to keep kicking everyone out of the main app to update it... (no, I have not developed a auto-update routine yet <g>)


Thanks,
- Brian