>>Microsoft is not making any attempt to migrate or move VFP developers away from VFP into .NET.
>
>Yes,
>it only push the clients of VFP developers to migrate into .Net. That is the reason I to ask you from a year to see VFP.Net. With that abreviation, we can gain a little bit from mass advertising of .Net products

This issue has been addressed often here on the UT, and directly by me in the article I wrote at http://www.advisor.com/Articles.nsf/aid/LEVYK02...

Next version of Visual FoxPro

The next version of VFP is code-named "Toledo," a name selected by the FoxPro community just before Visual FoxPro DevCon 2001. The main top-down goals for Toledo are to provide a better rich client, improve distributed Web client features, improve developer productivity, and increase discoverability for ease of use. You can see that the product direction focuses on features VFP developers have requested.

Visual FoxPro 7 includes a high-performance runtime language/database engine that is COM-based. The VFP 7 data-centric language is tightly coupled with the database engine. The architecture for Toledo will remain the same as the previous version of VFP for performance and technical reasons. Toledo will continue to use the local fast FoxPro runtime engine in unmanaged code, rather than move to the managed .NET runtime.

Toledo will not be part of Visual Studio .NET and will not compile to the .NET common language runtime (CLR) engine. VFP is a language, a database engine, and a development IDE all in one. Having the FoxPro language compile to the .NET CLR would mean removing most data-centric commands, then using VS.NET and not VFP to do development, thus eliminating some of the FoxPro language, the VFP database engine, and the VFP IDE. VFP 7 is fully-compatible with .NET via XML Web services and has a new OLE DB provider for great integration with VS.NET and ASP.NET. And we're working on improved SQL Server connectivity for Toledo.