>>The future of VFP doesn't depend on whether or not it partipates in the CLR. From my POV, it would be a gross mistake to make VFP a CLR compliant language. The mindset of some people is that "everyting belongs on the Internet/Intranet".
>Who said it is? .NET CLR is not only internet/intranet thing because there is WINFORMS.

Though I doubt I can do it, let me try put this subject to rest. AFAIC, I don't know anyone who knows anything about the CLR and what it means to VFP who's in favor of VFP participating in the CLR. Then again, I don't know, nor do I presume to speak for everyone.

There are three basic scenarios here with VFP and the CLR. To enumerate:

1. VFP becomes a CLR compliant language. Like it or not, this probably means the death of VFP. VFP would have no data engine, and none of the functions it has to do what it does best: munge data. There would be no compelling reason not to use VB.Net in its place.

2. VFP becomes a CLR compliant language, but the CLR is modified to handle the additional data munging capabilities. This would mean that both VB.Net and C# gain the same capacities. Again, there's no compelling reason to use VFP over the other tools.

3. VFP is modified to produce both managed (to run under its own run-time) and unmanaged code (to run under the CLR). The question is, "Why would Microsoft do that?" The answer is that they wouldn't because there's no profit in it. One of the reasons that C/C++ can do this is that the language is used to produce future versions of Windows and applications. Therefore, there is a return on the investment. The only return here is that it would make some people happy.

Winforms is not any sort of compelling reason for VFP to be modified towards the CLR. VFP's internal memory management system is not standard and what you would end up with is less power because of it.

The mantra of using the "Right tool for the job", is a correct one. I, for one, don't want VFP to become a "Swiss Arny Knife" of languages. I've got VB for that.