>>I tend to agree with your view on the ongoing discussion. What I think is best for both camps is to have an option for VFP the ability to compile to CLR (with some lost of functionality and other added benefit of CLR environment).
>
>Hi, Kim.
>Problem is that this is not an option. Running VFP in the CLR would not imply some lost funtionality but most.
>
>The CLR can't handle things like USE, SCAN, LOCATE, REPORT, etc. It can't use language statements to manipulate data, and if you took out this from VFP what is remained? A weird Pascal??? You have VB.Net -or C#- for that.

I have heard this mentioned several times, but I don't believe it is entirely true. Certainly it is possible to create a compiler/translator that would take FoxPro code and produce MSIL, just as the other languages will do. Our favorite commands and language elements would be transalated into equivalent CLR calls or blocks of code. Obviously, this would be more difficult for VFP than for the other languages, because they deal with the .NET framework directly.

With this in mind, I would support VFP in the CLR under two conditions:
1) All or most of the language would have to be supported. If I can't use my existing code, then what's the point? As others have said you might as well use VB.NET or C#.
2) CLR compilation would have to be optional. Theoretically, there would be an option on the Build Project dialog to compile to the CLR. The traditional VFP runtime would still need to be available.

This raises a few questions:
Would Microsoft spend the money on VFP to have the full language compiled for the CLR? Probably not, but I think it at least deserves discussion. This would definitely be a difficult undertaking, but that's why we have compiler writers <g>.
How well would VFP CLR code perform? Not very well. I would expect it to be slower than other languages, since we would not be making direct calls to the .NET framework. It would compare even less favorably to the same code running with the VFP runtime. This also brings into question how many developers would make use of the CLR option.

For VFP7, I think it is the right call not to add CLR support. But in two or three years, .NET and CLR support could be very important to us. By the time VFP 8.0 or 9.0 (am I being optimistic? <g>) rolls around, being able to use existing code with the CLR could prove to be very valuable. Right now, it is just too soon to tell.

Last question: Would removing VFP from the VS box now damage the opportunity to provide CLR support and further .NET integration in the future?

Joel