>That's simply not true, because VFP -is not- a dotNet language. There are assumptions about dotNet which will not apply to VFP; the most immediate example is portability. VFP is a Win32 product; if someone comes up with a Linux/Mac/BEOS/Solaris/Palm port of the CLR, your VFP apps will not move to the new environment unless, in addition to a CLR implementation, there's a Win32 emulator. Many aspects of dotNet are omitted in VFP; a simple example is the thread model options open to dotNet apps regardless of the development language; VFP remains a single apartment threaded environment.
>
>Why do you feel a need to deceive the public or weaken the meaning of dotNet? dotNet is not the same as Microsoft owned and approved; it refers to a specific arena that, while we can freely interact with it, we don't get all the benefits (or all the problems) of playing directly with it in the sandbox. Let's not confuse the issue of what dotNet means just to get a couple of people to let you use VFP where VFP rather than a dotNet language is the right tool for implementation. Instead, work on educating the public about choosing the right tool for solving a problem.
>
>My experience is that, bottom line, most clients want results from the finished product much more than they want buzzwords. We aren't sales critters, we're problem solvers, at least in theory. Go solve problems rather than make new ones!

Ed:

Couldn't agree more! It would be a mistake, and a fake. I'll vote no on this one.