How to update copies of my pgm (on Local LAN)

What is the best way to replace my VB's EXE, in each of the user's pc's ?

I am working on a pgm that will be used on a local LAN (approx 10 users).
It is VB6, and it uses an Access DB (97). (DB will be on the server.)
It is being tested by users, and there will be frequent updates to the source code.
Each user has a copy of the pgm in a folder in their 'C' drive.
I have already solved the issue of the pgm knowing where the DB is located.
The end result of that solution being, each user has the required path stored in a local INI file.
At the moment there is only 2 users testing it, and only one of them has Winzip.
Emailing the latest version to him (him with Winzip), is pretty easy, and guiding him to replace his EXE, is also easy.
The second user does not have Winzip, and the Windows XP zip extractor is a pain in the butt.
(Hard to find where it went, and it's creating parent folders/paths instead of just extracting the EXE.)
I tried sending the EXE but it got blocked.
If I tried creating a winzip self extractor, I presume it too would be blocked.
Here is my proposed solution -
I will have a version of the EXE on the server.
Generally it is not used, but it will be, on rare occasions.
When I compile a new version of my EXE, I will somehow earmark it with a date/time or a version number.
I will send it to the user with Winzip (the owner of the business).
He will unzip and replace his EXE.
When pgm starts, on any pc, it checks it's 'version' against the copy of the EXE on the server.
If the server's version is older, it will offer to replace the version on the server.
If the server's version is newer, it will offer to replace itself with the version from the server.

Does all of that sound feasible ?
Can the EXE replace itself, whilst it is running ?
Is there a better way ?
Any words of advice prior to me starting on it ?

Thanks,

Yes, it is feasible and I have done something along those lines, but, and Exe can not replace itself.

I solved this problem by writing a seperate .Exe and gave it the exact same icon as the .Exe of my real program, so on a desktop short cut, it appeared to the user that they were actually running the real program, rather than what was nothing more than a "version checker" program.

The version checker program looked at the version on the local drive and compared it to the version on the server. If they matched then it left everything alone and executed the real program .Exe.

If the version on the server was newer than the version on the local hard drive, it popped up the a message requesting the user upgrade. Presuming the user agreed, it copied the new Exe from the server down to the local hard drive. It could easily do this because the actual program was not running. Then, after the copy, it executed the real program for the user.

Sound doable?

What is the best 'thing' to check for in the File ?
I normally use native File calls, not FSO.
Can I check version number with native File calls.
I presume I would just be setting the version in the IDE via Project Properties 'Make' tab ?

Or, would it be simpler to check File created/modified dates ?

Thanks for feedback,

I used the GetFileVersionInfo API which is a bit more involved. But I prefered using the API as it checks the version of your .Exe that the OS understands (the number on the Version tab of the properties page you get when you right click on file in Windows Explorer) which may not necessarily be what the app.major/app.minor VB information is.