>Dana - Thanks for the reply. The reason the application is run from the server is that it is an ever changing application. The .exe gets recreated often, sometimes even several times a day. When the user launches the application, they are actually running a tiny Visual Basic exe that looks in the target directory for the newest .exe and runs it. This way, I can update an application and the user can run the freshest version by exiting out of the application and restarting it. Since the common updates are not critical updates, but new features being added, I can have a specific user restart the application to get the updates without making the rest exit out.

Mark,

This can still be done on the client. We had a similar setup where I worked. A startup application would check for a newer version on the server, and if one was found, it would download the .app file before starting it up. As in your situation, those already running it could continue and shut down and restart at a convenient time to get the newest version. This allowed us to put up emergency fixes at any time, allowing those who weren't affected to update when convenient, while those who needed the fix could update immediately as it became available. So still, running the app on the client is the best way to go. And although this was done with a .app file, the same can be done with a .exe file. The only time the client would require a new setup (install file) is when a new dll or activeX or class file was added. Modifications to existing routines, or even new modules that were simply code, or used classes that were already in the application, would not need a new installation run, but simply need the .exe file replaced.

In closing, I must still agree with our other colleagues that running the application on the client is the best way to go.

Dana