>Assume that I have an auto-updating VFP EXE that is distributed and installed throughout the enterprise. Here is our protocol: When a newer version of the EXE is built, it is placed on a intranet webserver, available for HTTP download. When this application starts up on a client machine, it always invisibly uses the LoadURL routine (thank you UT) to grab configuration information from the web server, and will then (if appropriate) spawn a tiny VFP applet, and then itself exit. The tiny applet will download a newer version of the main EXE, again using the LoadURL routine, so that the newer build unmistakably overwrites the old one (this gets around the access denied problem with trying to overwrite a loaded EXE). In other words, we don't rely on the end user for downloading the newer EXE to the appropriate folder. What I'm trying to figure out is the easiest and most reliable way for an Active Server Page script to sniff an EXE (i.e., sniff the newest build sitting on the server)
>for its version information and send that info back as a simple web page to a client. Right now, whenever a new build of the EXE is created, we manually update this config file with a single line of text that contains version information on it so the client's EXE can tell if it needs to update itself. Diggez-vous? Thanks very much!

---

From VFP Help:
AGETFILEVERSION( ) Function
Creates an array containing information about files with Windows version resources such as .exe, .dll, and .fll files, or automation servers created in Visual FoxPro.

So you can use this function in your VFP code, or to create a COM component to use in ASP. Another possibility is the Windows API function GetFileVersionInfo.

HTH