>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.

If there was a VFP.NET, it would have to compile to the CLR and use the .NET Framework like other .NET languages, and would NOT be backward compatible with VFP 9.0 code. Moving your application from VFP to VB.NET, C#, Perl.NET, Delphi.NET, etc., or a VFP.NET if it exists, would be very similar and would have to be rewritten to use the .NET Framework, ADO.NET, etc. This is why there is no benefit to a VFP.NET if a future VB.NET and C# have many of the great features VFP has today but within the .NET platform.