After reviewing this thread and speaking with another VFP developer, I'd have to agree with Mr Strahl. I get the sense that one of Ken's goals is to convert VFP developers to VB.NET. I've never seen a Product manager so excited about another product and so enthusiastic to promote it. Should we also consider porting to Access?

I'm sure that .NET has several advantages over VFP just as VFP has cost advantages over .NET when say used in conjunction with Rick's West Wind Web Connect. I suspect WWWC can beat the crap out of a .NET app on a cost basis and probably on a performance basis up to a point. VFP can be used to develop cost effective applications for small businesses on or off the net.

Excuse me if I am not terribly excited about jumping into VB.NET or C#. Looks like either one would take 6 months to a year to become as proficient as I can be with VFP right now.

Two of my neighboors work as managers in the IT field for two seperate Fortune 500 companies. I asked them about their plans with .NET. Neither one has any plans whatsoever to even consider .NET. The following link on the Fox.Wikis site may also be of some interest:

http://fox.wikis.com/wc.dll?Wiki~DotWhyShouldI~SoftwareEng

Here is a recap of what Ken had to say in a previous post - emphasis added:

-------
VB .NET is a much better choice for most VFP developers (especially long term), only a short list of reasons below:

With/EndWith - in VB.NET and not C#

Late Binding Support – VB.NET natively supports late binding to objects

More “Fox like” Event Binding – VB.NET offers the HANDLES keyword allowing you to handle the 80% of eventing cases where you just need to tie a method to its event.

Parameter handling – VB.NET supports optional parameters – just like VFP

Background compiler – The VB.NET background compilation engine allows its intellisense to provide more help as you’re coding – just like VFP

Not case sensitive – Just like VFP

VB.NET will continue to gain more and more VFP like features while C# probably won't.

-------

>>>VB.NET will continue to gain more and more VFP like features while C# probably won't.
>
>I don't see this as an advantage. First off I can't foresee that the VB language would implement specific features in the language rather than using the framework to provide that functionality. If this MS' direction then it's shooting itself in the foot - if new functionality is introduced it should likely be implemented in the framework so that all languages can benefit from it. By putting stuff like that into one of hte languages, cross language benefits go out the window in a hurry.
>
>This sounds to me like you have a stake in this. What's the story here? VFP team working on migrating developers using VFP to VB.NET via merging functionality?