Michael,

>>A VFP .Net would simply be VB .Net.
>I Agree but why not move VFP towards being CLR compliant.

That would be like pushing a car towards the edge of a cliff... <g>

>
>>All data access would be through XML or ADO .Net.
>Why? Are you saying that VFP's native data engine could not be ported to code that is CLR compliant? How about the entire VFP runtime for that matter.

Nope.. The VFP runtime engine won't peacefully co-exist here. VFP gains a lot of its appeal directly as a result of the behavior of the current engine. Remember, CLR is the new engine and unless CLR becomes VFP-compliant it won't happen. However, the two can peacefully co-exist via COM+ etc.. See Craig's answer below re: web services

>
>>VFP 7.0 can participate in .Net now by creating and consuming Web Services.
>Yes but that doesn't even begin to compare with the ability to drop a class right into a .NET project. If I need VFP capabilities from within .NET today I would be forced to use a COM wrapper. In a year or two does the term legacy come to mind.

Sure, but remember that the issue here is tradeoffs.... To make VFP CLR-complaine would essentially rended VFP into VB. Just use VB.NET in that case and keep using VFP for what it is best at.

All that is required is learning a new language and if you've learned VFP you can surely do this.