Jim -
near as I can remember [and you can search here too].
1. You'd lose the data engine of VFP.
Many people here, myself included, saw that as a bad thing.
2. There was time to market issues with getting VFP 7 out the door,
and it was decided to break out VFP 7 release from anything to do with a release date for the .NET set o MS tools.
3. IF there was to be the exact functionality mapped 1:1 from VFP as it is now, to a .NET implementation of VFP, clients' installations and sites would require a MS 2000/3-like server to 'serve up' the app to a browser. This is a cost-constraint for many SME's both for hardware acquisition costs and admin personnel costs.
3. The design paradigm for Windows Forms would go through a massive rewrite, and that camp did not want the functionality of VFP to be included (my opinion).
4. Where's the data store ?? This kinda relates to #1 here, but was a huge issue as well. Lots of evangelical discussion about 'wait for the next ole-db driver for VFP - it will work with dot net.


I agree with you from a coding and syntatical standpoint - C# and VFP are very similar. Was this a good adherence to OOD and OOP standards for an OOP language ? I would like to think so - one of these things that kinda slipped through the cracks and it actually made sense.

You may want to spend half a day searching through the archives here for some detailed discussion and q/a- it was most lively, as I recall, for about 4 months.

mondo regards [Bill]