>Let's say there was a VFP.NET language added to VS. And let's say various VFP-like data features were added to VB and C#. Then what would happen is that IT shops and companies would ask "Should I use VB.NET, C#, or VFP.NET?" The answer would be "VB.NET and C# are more strategic and have more resources on their teams, and VB has the same exact functionality as VFP.NET since data stuff was also added to VB.NET.". Then all the samples out there would need to be in VB.NET, C#, and VFP.NET, all the same features added to VB.NET would have to be added to VFP.NET and it would take away from the overall features added - even when VB.NET had "all" of the same functionality as VB.NET. If there was a VFP.NET, it would not have one feature more than VB.NET. So why would someone want VFP.NET, what would be the benefit both technically and marketing wise?


Ken,

The reason we(/I) want a VFP.NET, is that in my company, we have several large products that are written in VFP, and it is from selling and upgrading these that we make a living. The applications are so large, that they cannot be rewritten in some other .NET language without a huge amount of resources beeing allocated - resources that we do not have.

Now, since it is form these products we make a living, I am quite concerned when I read that VFP will not be made a .NET language, will not compile 64 bit code, will run only in compatibility mode (kind of like NTVDM?) on the next versions of Windows etc. In fact, MS will not even say that there will be another version of our primary development tool.

I am sure you understand my frustration, and please take such scenarios into consideration when planning the future of VFP.

Eyvind.