After many, many years developing with VFP and the superb Codemine framework doing typical data oriented applications in which VFP shines, I can honestly say that with .NET 2, C# and my current .NET application framework (StrataFrame), I am at least as productive doing the same type(s) of applications in .NET. In addition, I am able to do many more things in .NET that seem trivial compared to the hoops I had to jump through using VFP.

The current application I am working on is a .NET re-write replacing a very large VFP/SQL server system. I am able to handle all of the data requirements of the business using my .NET tools. Additionally, the .NET version of the application justs "fits" into the enterprise environment with so much more synergy than VFP ever did or could. What I do miss is a "local data engine" so, that would be nice in .NET - however, it is not an insurmountable issue; I miss it because I had it in VFP - all of my .NET colleagues never, ever talk about local data storage; it isn't even on their radar. The only other noteworthy feature from VFP that I miss is in-line SQL but it is clear that LINQ will really take up the slack in this area, in the future.

I have always been a great fan of VFP so I would not discourage anyone from using it. However, for one, I personally don't feel that three months is enough time to become truly conversant in .NET when compared to the amount of time you have spent with VFP. Also, whenever I re-visit VFP code, it just looks a mess to me. After using C# and .NET's vastly superior OOP model, VFP syntax looks clunky, inconsistent and verbose.

I am sure your decision is right for you but I for one am glad that I invested the time to really understand .NET. I see VFP as "legacy" and .NET definately the "future".

Just my .02 cents.

Best,

-=Gary




>I have a substantial project to develop and decided to spend the money and time to seriously evaluate dot Net. The first month was "oh god, I'll never get this". After the third month I felt I could develop reasonable, sound code in .Net using C#. I experimented with using SQL, SQLExpress and VFP as the backend data sources. Candidly, the data handling in C# is clunky. There is a lot more code to write to get results that are easy to obtain in VFP.
>
>My conclusion is that for most developers, .Net is not ready for prime time.
>
>I also estimated how much money (read salary expense) it would take to develop a fairly sophisticated application in C# as compared to VFP. Again, VFP won.
>
>Before people start shouting, consider that I made a serious effort to learn and understand C#. Can you set aside 3 full months to work exclusively with C#? That's pretty much what I did, and it was a very expensive undertaking for our firm.
>
>Let me say that there are many many features in C# .Net that I would like to have in VFP, more controls in the foundation classes is a big item and the ability to be more creative in building user interfaces in C#. Microsoft gets an "A" here.
>
>But my bottom line, is that C# .Net development is cumbersome and is a much slower development tool than VFP, even allowing something for a disparity in experience (more experience with VFP).
>
>From the perspective of Microsoft, I can understand why that corporation thinks C# is the greatest thing since sliced bread. And if I had big budgets and multiple engineer teams available to me, I might agree.
>
>However, we are a small shop with two primary developers and two developers with somewhat less experience. The .NET promise of RAD does not hold up very well when compared to VFP. If you are a C coder, then C# is much faster, but not when compared to VFP.
>
>In the end, whether developing with C# .Net or VFP, my customers will be able to query the same data, get the same reports and otherwise have the same experience on either product platform. So if it cost me more time and money to develop in C#, and the end result is the same; then from a business perspective, which product platform should I choose?
>
>Regards
>Don Lowrey