>Ahhhhhhhhhhh, I see. In that case, the ideal solution (in my eyes) would be the option for an automatic update of those files where the developer (or the user if the developer wanted to allow that option) could toggle a switch on/off to enable or disable the feature when necessary.


Exactly. Maybe some sort of "key" distributed and controlled by the developer. That's really off the top of my head (which is a reflective surface and does not filter ideas effectively). Maybe a dumb idea. But there are enough smart people at Microsoft to figure out an implementation strategy!

Also, don't Win2K and WinXP support multiple simultaneous versions of "the same" files, so that apps that need different versions of runtimes, dll's, etc. don't get crossed up? (Please correct me, OS-philes out there, if I'm off-base here!)

So, if your app was installed on a computer, and mine needed a slightly different version or patch-level of a runtime file or DLL, the OS would maintain both of them, and not overwrite one with the other. If that's a reality, the "key" might not be necessary.

I'm sure we agree on the ultimate goal of deployment ease and scalability with reasonable (if not bullet-proof) runtime reliability.

Again, I'll defer to Microsoft how to make all this happen. I appreciate the comments here about VFP runtime deployment, and options for the future.