You pretty much make the case right here in your post as to why there is no VFP .NET. Why? Becasue it is not needed. For one thing, C# is in many ways - familar territory. Second, there is the VFP Toolkit for .NET.

The one feature that separates Fox from other tools is the tightly integrated data engine - which is 100% counter to the philosophy behind .NET.

The only people that would be remotely interested in having the language ported over are Fox developers - which is not a big market. If Fox developers want a more declarative type language to work with - there is VB .NET.

80% of what you do in .NET is with the Framework - which is langauge independent anyway.



>Hi All,
>
>Just finished my first (small) application in C#. Any VFPer who has learned C# knows that it is so close to VFP in orientation and philosophy that it is certainly much easier to move from VFP to C# that from C++ to C#. Were I not already familiar with OOP as implemented in VFP, I think C# would be a struggle to understand.
>
>In fact, it is easy to conclude that C# is fundamentally VFP with odd syntax. The marvelous 'innovations' in C# have direct analogs in VFP. Compare, for example "Using ...;" to "SET LIBRARY TO ...". Just another way of accomplishing the same task. A lot of comment I have read makes much of the fact the VFP allows function and C# does not -- everything in C# is a class. Actually, if one creates a class called "functions" and puts all the typical user defined functions in the class, there is not much practical difference.
>
>Which leads to the question, Why not VFP.NET?
>
>What would be required to make VFP work as managed code?
>
>1. Strict variable typing. Not much of a problem. All migrants from Clipper have been through the experience of converting all their code written for versions prior to Clipper 5.x to use strict typing. As I recall, it did not result in great mahem. Enforcing strict typing so errors are caught by the compiler and not by the customer at run time is a very good idea in any case.
>
>2. Commands restated as Functions. Again all writers in Clipper 5.x remember when Clipper eradicated commands and introduced equivalent functions. USE.... became USE(). It does not require much mental adjustment to make this change. Don't we usually wrap common commands in user defined functions anyway, if for no other reason but to return an indication of whether the command was sucessfully executed? Commands are an anachronism that should be exterminated in any case. Native functions would be a better choice.
>
>3. CLR Compiler. Instead of compiling to p-code, how much more difficult would it be to compile to Common Language Runtime? It seems to me not to be a practical problem, but a political one. Someone just has to allocate the resources to do it. We could have the choice of a p-code or CLR compiler -- pick it from an IDE menu. Again, back to my Clipper experience, I remember we had a choice of at least two compilers. There may have been others that I never used.
>
>So, Microsoft, what is the problem? Wouldn't this approach make VFP much more mainstream and do a lot to reduce the constant VFPer complaints that Microsoft is not really supporting VFP?
>
>I think it would, and would add a powerful development to the .NET repetoir.
>
>Or is there an insurmountable problem that I just don't see?
>
>Regards,