Thank you for your comments (it’s great to see your name)!

I don’t think that the VFP syntax is important. So creating a CLR ‘version’ seems a bit counterproductive and pointless (so I agree that it isn’t a solution).

The true worth of VFP from my POV has always been VFPs position as a RAD tool, its cost and licensing structure, its string handling capabilities, and of course its native database. These four things make VFP a very powerful tool to develop everything from full scale, multi-tiered apps to basic prototypes (and everything in between).

Don’t get me wrong, though. I like C# very much. I’ve also been programming in PHP for several years (and like that, too). I am currently working on a huge Data Warehousing project using SQL Server 2005 and various other tools. I just feel that the issue (from MS) isn’t about ‘moving on’, but more about the bottom line: VFP clearly cuts into the more lucrative .NET/SQL Server ambit. And in some ways, VFP is better!

I don’t think the 64-bit is an “excuse” as much as it is their reason for moving forward. Look, they dumped FrontPage to recreate Express. VB 6 into VB.Net. VB 6 is never going to be 64-bit either.

I think your points about FoxPro’s appeal are very valid – but if your reason for not jumping to C# is Rushmore with Native DBF support, then I think you’ve shown why they would never do it.

They want developers to embrace the LINQ model, SQL server DOES have rushmore technology now, so you’ve got an OLE DB provider to give you DBF support, LINQ to give you data access and now what is there to keep you in Visual FoxPro and not in C#?

My answer would be the overall architecture of the IDE. The entire “hack it yourself” approach, while yes, you can do it in Microsoft’s newer environments, they just don’t feel the same. I know that sounds fairly “vague” or “sentimental” but I think it’s a valid statement.

Vista (or its server successor Longhorn) is Microsoft’s last 64-bit OS – after that, they will be rebuilding (yet again).

If they could recreate FoxPro in a 64-bit IDE offering but with native DBF support (as well as SQL, etc), would that be the solution? Well, Microsoft wants their languages to be VB or C#. You want something else? Build it yourself. Someone mentioned something to me about a possible VFP-syntax like addition to the CLR. Then you work in the Visual Studio IDE (which Microsoft wants) but have your own language. (The FoxPro DotNet toolkit was one – not sure if there’s another initiative)

Would that answer the demands of VFP developers world-wide?

Sadly, I don’t think it would. Just my two cents.

So what? strip out DBF support but leave internal cursor technology (this means, the ability to create and manipulate memory cursors). This way we can use VFP as a frontend for SQL Server (or whatever) and Bill AND we would sleep better.