>>>
>>>Some people I respect argued that VFP should not be part of .NET. Their argument won out. In retrospect I consider the developer-driven decision to bail out of VS to be the fatally wrong decision.
>>
>>I never understood the rational behind people wanting VFP to be just a standalone tool.
>>
>>If it was the flagship tool of a company (other than Microsoft) that would obviously make sense, but when Microsoft is pushing EVERYONE to Visual Studio, why not keep VFP in it?
>>
>>Makes no difference now, though.
>
>
>In addition to the things that have been mentioned by others, there was a great reluctance to give up some things that (it was believed, anyway) would have to be dropped to fit into .NET. Macro substitution, for one thing. Basically it was thought by some that so much would be lost, it would hardly be FoxPro any more. And maybe there was something to that. But in terms of market perception, being dropped from VS sent a terrible signal.

Supporting backward compatibility was the greatest mistake. It forced to keep lot of old stuff, most likely making source bulky and hard to maintain. It is nice to have 5 ways to do the same thing, but if 3 of them are pretty old and unusable then it does not make sense.