> 1) All or most of the language would have to be supported.

I really don't think the difficulties associated with this are being stated strongly enough. Start with something simple like USE Customer ALIAS Cust. Q. What's the CLR equivalent? A. None. Now take all of the things you can do to Customer after you use it, gone too. The concept of simply having a table open and being able to read from it, write to it and move the record pointer within it are completely foreign to VS.NET.

The next thing to consider is, is this even desirable for the .NET platform in general? I really don't think so.

Think about what it would take to support a VFP report form:

1. The whole data engine for two reasons, one to get data to report on and two because VFP reports are actually DBFs.

2. The ability to render a report from the VFP DBF.

3. Support for all of the various clauses on the REPORT FORM command

4. Printing. (I imagine that VS.NET can print, but does it actually have something akin to reporting? I think it uses Crystal.)

> If I can't use my existing code, then what's the point? As others have said you might as well use VB.NET or C#.

Right on. If you have to rewrite and you have to learn, who cares if it's C#, VB.NET or VFP.NET.


> Last question: Would removing VFP from the VS box now damage the opportunity to provide CLR support and further .NET integration in the future?

I think not for two reasons, one being, there's nothing that would preclude VFP from going back into the box that I'm aware of and two being that I don't really think there's much of an opportunity to begin with.

I used to really want a CLR version of VFP, but after thinking it over and listening to the arguments that have been made against it, I don't really see any value in it without nearly the whole language, but from the VS standpount, I also don't really see any value in putting the whole language into the CLR either.