>>I don't see any reason why this should happen either. With VFP data yeah, there's a big problem with the EXCLUSIVE requirement for files but with SQL Server no such issues.
>
>At this point VFP isn't making it easy for to stay with it. I've went from all 3 tiers being VFP, then changing to ASP.NET as the UI tier (since VFP doesn't have a drag and drop web UI designer), I expect to move the data tier to SQL in a few months because of this DLL unloading problem. Now we are down to only the biz tier in VFP. Who knows, after playing with SQL for a while I will start using stored procedures as part of my biz tier, or C#. < insert gratuitous sigh >

I think I've said this before: VFP is good at what it does, but when you throw it into a .Net solution it's more of a PITA to do things that way and you don't get a huge amount of value from it in that environment.

If you're using C# and SQL already and you're using business objects it's only a small stretch to see that you might just put the business logic into C# as well. COM Interop works, but it basically has the same issues that you had in classic ASP, plus slower performance, and the whole early binding issues which make versioning on the Web server much more difficult.

VFP is great as in a .Net solution as a transitional technology, but over long term I don't see many people sticking to it in a .Net solution. It just doesn't make sense to give up all that .Net has to offer in terms of the development process...