Actually, Cobol for .Net is available. http://www.netcobol.com/products/windows/netcobol.html is just one of them. There is apparently a Pascal version in development: http://www.tmt.com/net.htm. And of course there is Delphi: http://www.borland.com/us/products/delphi/index.html

Originally MS had a valid reason for not porting VFP: no one had demonstrated that dynamic languages could be integrated into the CLR. That ability is now demonstrated in a released product (IronPython 1.0, under continuing development). The reason given now is resources, but of course in a company that added 10K employees last year, that's laughable. The reason is a marketing decision, made by those who want to protect their little fiefdoms within MS, a phenomenon noted for years in the local MS offices, who on some reported occasions declared that VFP was dead -- 2 or 3 versions before VFP9.

Hank

>Hi Joel
>
>>but the last I heard VFP will not work with Dot Net because of the CLR.
>
>Aren't VFP apps supposed to work in the OS, namely Windows, which it does, and will even in Vista, I believe.
>
>I don't think that C or C++ code can be compiled in VFP. VFP code cannot be compiled in PASCAL, and so on, so isn't it obvious that a compiler will compile only stuff that it is supposed to compile. Is this a discussion point? If so, then we should be complaining that my old COBOL code too is not being compile in Dot Net becuase of the CLR.