I just signed on to Universal thread (for the first time in quite some time anyway), and I notice that there is a survey to name VFP 8 VFP.Net or something .Net'ish.

I have been working with VFP for about 3 years (With Delphi for 5 before that), and now we are transitioning to C#. It's not my intention to slam the tool here, although I know my comments will sound that way. Instead, I would really like these comments to be taken as a challenge to the VFP team.

First, my answer to the survey:
Yes. Build a product named VFP.Net.
--And-- No: Don't name VFP 8 VFP.Net.

I see nothing about VFP 8 that specifically lends itself to .Net. Sure, it can interoperate with .Net, but I don't see any sign that VFP 8 has embraced the .Net architecture.

I don't see that VFP offers particularly good integration with .Net. Here are the reasons that I feel this way:

1. VFP 8 only interoperates with .net via COM Interop. COM Interop is a .Net capability. All .Net classes can be made available to COM consumers, and .Net code can act as a consumer of COM objects. This is an inherent .Net capability. You can leverage it via VFP, but VFP has done nothing special to provide this capability. Any COM compliant tool can do this.

2. The VFP 7 OLEDB provider doesn't even work correctly with ADO.Net. We have been promised a fix for about a year. I don't know whether the provider with VFP 8 addresses the problems. There are some bad problems (acknowledged issues that have been discussed elsewhere) where you are unable to update VFP data with ADO.Net. This is not due to a problem with ADO.net. There is an acknowledged problem with VFP's ole db provider.

The fact is, I can think of no good excuse for VFP 7's oledb provider to not work with ADO.Net. They were both developed by MS. MS had been working on .Net for 3 years at the time that VFP 7, and the oledb provider were released.

3. VFP 8 included a new Cursor Adapter Class that should make working with native cursors, ODBC datasources, and ADO data sources homogenous. I notice that ADO.Net is missing from the list. How can we claim "excellent integration" when this new data feature completely excludes the preferred means of data access in .Net?

4. VFP 8 doesn't emit managed code. .Net is all about the CLR and managed code execution. VFP 8 doesn't emit a scrap of managed code.


So here is my opinion: Yes, make a VFP.Net. But don't name VFP 8 VFP.Net -- that would be lying. Release VFP 8. When you start working on VFP 9, pour real effort into making it .net compliant. Heck, at least go for 3 out of 4 of those points. Then consider naming VFP 9 VFP.net.