Before I get started on this, let me reiterate what my point is, and what my point is not.

My point that VFP 8 should not be named VFP.Net, because it really isn't based on .Net technology.

My point is not that VFP is inferior or superior to tool X. We've all been in those arguments before, and frankly they're kind of boring.

I see MS considering rebranding VFP with a name that is misleading. I feel that this is an opportunity to make a difference. To tell MS to end this branding and rebranding marketing game and call a spade a spade (and a fox a fox <g>)

>The VFP 8.0 OLE-DB provider (beta) was released with the VFP 8.0 public >beta and it fixes these issues. Has VS even been out for a year? How can a >fix to work with a product that hasn't been out for a year have been >promised for a year?

The product may have been in a promised state for a long time, but it was in development for an even longer period. VFP's OLE DB Provider could have and should have been compliant. I very much hope that the VFP 8 provider addresses these issues. If it does, then we can remove this from the list of grievances.

>ADO.Net is a .Net component. You still use ADO (COM) to access OLE-DB >providers with VFP.

My point exactly. How can we call VFP 8 VFP.Net when it does not provide integration with .Net components?

>VFP has been using managed code and a runtime for years. Back then, >everyone trashed it. "Not a native more compiler, etc." Now you want them >to run against a runtime that they didn't write.

VFP has been using interpreted code for years, yes. But that's not remotely similar to the managed CLR code. For one, managed CLR code is just-in-time compiled, so you get about 90% of the performance of native compiled code. In our testing, it is orders of magnitude faster than VFP interpreted code.

But hold back, I'm not really trying to start a flame war between .Net and VFP. I'm trying to point out why VFP 8 should not be named VFP.Net. So, the final argument still stands. Real .net code enjoys benefits that you cannot gain through COM interop.

The point still stands: True .Net development tools such as VB.net, C#, (even COBOL.Net) deal in CLR managed code, and they offer deep integration with the framework's extensive object library. VFP 8 doesn't. I'm not here to argue whether that makes VFP superior or inferior to the .net tools. I am arguing that it makes VFP _different_ from the .Net tools, and therefore VFP 8 should not be named VFP.Net.