>A discussion on another thread got me thinking about what I like in .C# .Net and what I like in VFP. The thought came into my head, that many programming languages, the ones developers really like, were not developed by the mega corporation. Fox Technologies is an example.
>
>So why can't we have a VFP(xx) platform that compiles on the CLR, runs within the Visual Studio IDE? Why not?
>
>Consider:
>1. What if the legacy xbase commands were stripped out of VFP(xx). This version would not run Fox code compiled on earlier versions of the language.
>2. The VFP data engine was omitted, but VFP(xx) was designed to use a backend, such SQLExpress or SQL, mySQL or VistaDB.
>3. It compiled to an intermediate language that ran on the CLR.
>4. The new Fox language remained data centric, within the above constraints.
>
>THEN: Why not include VFP as a .Net language? Microsoft could do this easily. (ARE YOU LISTENING MS?) If you think about it, they kind of had to do something similar to get VB into .Net.
>
>However, I think the opportunity is for a fast agile small firm, headed by a genius like Dave Fulton. After all, the CLR is open source.

There was a LOT of discussion of this some time ago here on the UT. Basically, there isn't a lot in VFP that can't be done with C# on .Net. To summarize some of the main arguments:

- Macro substitution: would have to go, difficult if not impossible to implement in .Net
- Loose typing (i.e. no strong typing): again, goes against the tenets of .Net, would have to go
- The fact that VFP is a somewhat "higher level" language than, say C# (maybe a 4.5GL to C#'s 4GL): you might have to write some code to emulate VFP constructs; some work has already been done with the VFPToolkit ( http://foxcentral.net/microsoft/VFPToolkitNET.htm )
- Local data engine/inline data language constructs - an admitted advantage of VFP over .Net at the moment; I understand the LINQ project at MS will help .Net in this area
- Local report engine - nice in VFP, just means you need to learn something else for .Net - Crystal, SQL Server Reporting Services etc.

So, bearing all the above in mind what would be the advantage of a VFP.Net language syntax over C# or VB.Net? Why would MS put resources into something like this? I think it would be a doubtful sell even to VFP developers who wanted to ease into .Net, because there's no way they could just take their VFP9 code and recompile it under some sort of VFP.Net. I don't think a VFP9 -> C# converter is realistically feasible either. If I were MS and trying to capture VFP devs into .Net, I'd put money into LINQ long before trying to support VFP9 syntax.

I spent a few months last year doing a small .Net 1.1 C#/ASP.Net project. C# is a nice language that isn't hard to learn - no competent VFP programmer would have any difficulty. Learning the framework would be the same whether it was C# or some VFP.Net so that doesn't factor into the discussion at hand.

IIRC, MS actually asked the community if we wanted VFP to become part of .Net, and for the general reasons listed above the community consensus was "No".

If you search past messages on "VFP.Net" or just ".Net" using exact phrase you can find lots of earlier messages discussing this issue. Some examples:

Re: Why Not VFP.NET? Thread #860155 Message #860250
Re: Want VFP on the CLR? Now's the time... Thread #1099834 Message #1100059