>Once out of the box, the issue no longer exists. Dot Net applications are targeted to a specific class of app that VFP is not. Again, this is why VFP should not remain in the box. Outside of the box, and with MS's support - VFP has a legit shot in the Desktop App. Market - which IMO - will be viable for some time to come...

But this would imply also that VFP has no place in an n-tier application, or inside the .Net plattform, what is not true. Even people from MS that doesn't know much about VFP (most of them) bought on the argument that VFP is excelletn for middle tier components.

Wouldn't this "Desktop App" strategy conflict with the market development of such applications as WebConnection based sites or Enterprise solutions?

I understand you point, but I'm not sure that it would be better than coexist on the box.

My current argument for those who ask about VFP not being in the CLR is that VFP is not a language at all, but a development environment that can't be reduced to the CLR. And that it is important enough for MS to stand side to side with the rest of the tools (i.e: it deserves its own icon in the VS startup).

Just my point of view.