>I have heard these arguments why VFP doesn't fit into .NET for a long time now. There are two things that separate VFP from VB. One is the language that is designed to handle data and the other is the fast data engine. If Fuji can put COBOL in the CLR why can't MSFT put VFP in the CLR? Add the data engine and using the language VFP would not look like VB. Unless they added SEEK (or other commands) to the VB.NET. I don't know.
>

Because .Net doesn't allow that. ALL DATA ACCESS IS VIA XML AND OLEDB. If something doesn't exist in the CLR, you can't do it. To put the VFP data engine into the CLR would require changes to the CLR that aren't going to happen. And, if it did, ALL .Net languages would be able to use it, again meaning that VFP and VB are one and the same. Putting Cobol into the CLR does not mean that COBOL is directly accessing ISAM files. It's using OLEDB and XML, just like ALL the other .Net languages.