>As to .Net, you can easily combine your existing VFP code with .NET. Also, you can do most of what you can do in .NET in VFP. IMO, .NET was developed to address the deficiencies in VB,VC++, and ASP, not VFP ...


Having been through this sort of thing for a while now I would suggest that this is a losing battle. Those people that use ASP.Net or .Net to call VFP COM components are very quickly going to figure out that it's easier to write the code in .Net instead of calling COM components. Aside from better performance, better debugging there's the whole feeling of consistency that comes from working in a single consistent environment.

IMHO, VFP works well if you use it as an end to end solution, but if you try to plunk it into the middle tier it quickly looses its appeal. That isn't to say that it doesn't work or even that it doesn't work well, but it's not integrated and it takes a lot of work to do well with it in there.

For some of hte articles I've written I've created a number of small sample apps and even though these apps were rather simple they were extremely difficult to adapt to using with ASP.Net due to the way that data is shared and exposed via COM. It was easy to do the same thing in an all VFP solution and it was easy to do it in an all .Net solution, but it was really messy in mixed environment. For my personal development I wouldn't go this route...

Now there may be legitimate reasons to use VFP from .Net - business logic that's established etc. but ultimately a lot of code will need to be written in .Net anyway that people will eventually realize it's easier to get that code ported to .Net.

Just my two cents...

I think ActiveVFP as Web Connection kind of sits more on the VFP end of things where it's not a pure mixed environment, but a framework that leaves most tasks inside of VFP and thus fits more in the 'All VFP' camp than the mixed environment. This makes more sense to me than the mixed environment for developing solutions quickly.