>>In the very long thread started last night about various topics in regards to user groups and related activities, it came in the subject that it would be interesting to know who would be in favor of having the VFP 8 naming to be geared toward .NET. As the product integrates extremely well with .NET, several members came to the conclusion that it could well be represented in the name. This would not entail any functional changes to the product, but purely a change in the way that VFP is presented and marketed. Instead of being an adversary of .NET, VFP would become a part of it, thereby changing both people's perception of VFP and the VFP community's perception about .NET. You are invited to cast your vote. This will be greatly appreciated.
>
>Great Idea!!!!,
>I fully support it. No body from my customers interested that VFP do not use CLR. They like to use most advance technologies advertised by MS - .NET. VFP.Net is perfect sales and promotion trick, from which all FoxPro community will gain.

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!