>i prefer mike's resolution-use installshield. i don't want runtime dll's or sps or anything updated on any of my clients UNTIL i've tested them first with ALL apps including with my framework!


We'll have to agree to disagree. From my standpoint, having to use InstallShield is the problem, not the solution.

If the developer can dictate and control the configuration of all users' computers, such as in a closed LAN or intranet, then manually applying updates is viable, though maintenance costs escalate as more users are added.

However, if user computers are scattered all over the world, where the developer cannot directly control the configuration, then automated installation and updates are sensible.

Of course, having the option to auto-update the runtimes or not, at the developers' discretion, would be ideal. I don't know if it's doable.

If the configuration can be controlled, then by all means doing so will help ensure a reliable runtime experience. But limiting applications to environments where configuration control can be enforced is simply not an option at this point in time.

In broad deployments, requiring the user to endure an InstallShield-style "windows setup" will not enhance his "experience", especially when he compares that to the relatively seamless "download and run" of browser plug-ins.

Since support for VFP apps (currently) requires installation of only a handful of files, and they don't even have to be registered with Windows if placed in the PATH, it seems a pity to accept the idea that a big setup ritual is an absolute requirement.

I'd like to see VFP smart-client ( or rich-client) web-enabled, SOAP-consuming apps have a chance in the .NET future. Mandating an IS-style setup is clearly an impediment to that goal.