Rick, yes, you're right, AVFP is a mostly VFP dev framework like WC. There's just the minimal static ASP.NET or ASP stub that calls the VFP mtdll which has all of the app logic.
There are still some quirky things when running VFP mtdlls from ASP.NET that I hope get ironed out by MS soon with the final VFP 8 or VFP 9. I think performance will improve (though, it's pretty good now with ASP.NET and as good or better from ASP from what I've seen) since MS is using the same technology for Web Services. Also, I think we'll see improvements just by more community participation in this whole area. The VFP COM debugging technique by Maurice de Beijer is a good example of this.
>>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.