>Hi Jess,
>
>Well, first of all thank you for your kind words.
>
>Now.. As to whether or not VFP should be a .NET-based/enabled product: I do not think it should so be. Most of the reasons have been discussed extensively here and elsewhere. The 'bottom line' that I have seen is that for VFP to participate in the CLR it would give up so much of what FoxPro offers as to end up making FoxPro not be FoxPro.
>
>So.. If you think about this a little here are the alternatives:
>
>1) Change VFP into something that would make it so similar to existing products as to effectively and thoroughly destroy it.
>
>2) Leave it out of the CLR and therefore keep those features that differentiate FoxPro from the other products and perhaps allow Visual FoxPro to extend itself into the future.

>IOW, it seems to me that your concerns about FoxPro's demise by not being a part of .NET are incomplete in that if FoxPro were to become a part of .NET it would no longer be needed. VB.NET could handilty take its place and the demise of FoxPro would only be more certain.

>My advice: Keep Visual FoxPro out of the CLR.

Doug,

To clarify my stand, my wish is that VFP.Net should compile to CLR thus getting WEB FORMS, ADO.NET, Crossplatform readiness, etc. but it should be backward compatible (Managed and Unmanaged Code) with its previous version.

It's more on how I could participate in the Major League using one major tool? And that's what VS.Net promoters is talking about: "Choose the language of your expertise and you are comfortable with." The demise concern is just a by-product if I am not mistaken. All are just based on what I've heard, observed, and seen in the software devt arena. Sometimes better to do something and found it is wrong later than by doing nothing at all.