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

I don't think there is a one-to-one equivalent for USE in the CLR, but ADO does support client-side recordsets and has methods to navigate, manipulate, and save those recordsets. In my mind, it would be similar to accessing a local .DBF table through a remote-view. Would accessing a .DBF with ADO through the OLE provider be as fast as USE natively? Certainly not. On the other hand, I doubt .NET would be used for anything less than client-server apps, where the performance hit wouldn't be as much. In fact, I wouldn't consider it too much of a limitation to require use of remote views or SQL pass-through for CLR apps. This should provide the connection information for ADO.

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

I agree. I had not thought about the report writer. It would definitely not be supported. Again, I don't think this is too much of a limitation for those requiring CLR support. My main concern is with CLR support for the use of the FoxPro language in code. I also think forms could be translated to make use of the .NET classes. This would be difficult as well, but possible. Did anyone else notice that WinForms produces MSIL code that can then be edited manually? I wonder where they got that idea <g>.

I agree that it would be very difficult to provide this level of support for the CLR. Would it be any more difficult than writing an X86 compiler? Perhaps that's an unfair question since VFP relies on a runtime.

Joel