Hi Jeremy,

If Microsoft were willing to market VFP on its own in a serious way, I'd have no qualms about your position. However, it's clear that MS is relunctant to transmit any marketing message that doesn't explicitly relate to .NET. There is no stronger marketing statement than a product's name.

You've argued against the name VFP.NET, but what about "VFP for .NET"? Did you see Revision of the VFP renaming poll? Does this help assuage the pain of violating your strict sense of propriety? As far as I'm concerned, either of these choices, VFP.NET or VFP for .NET, would be a major positive step for the VFP community. If the marketing won't come to VFP, VFP must go to the marketing.

If .NET is to be such a big success, let VFP aspire to someday being VFP.NET, content for now to be "VFP for .NET". I don't want to debate the relative merits of VFP and .NET either, because I'm not qualified and that's not the point. Still, it was very interesting to read Rick Strahl's article in the Nov/Dec issue of Code about "Dynamically Executing Code in .NET". Give 'em another ten years and they may catch up to VFP in that department!

Mike

>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.