This should be in the next version of ActiveVFP. Although you can 'Unload' the VFP mtdll locally after it's been called from ASP, it's more of a problem replacing code on a remote computer, like an ISP. With this solution, you just replace it, just like .NET. This solution also will work with a VFP mtdll called from ASP.NET which was another nagging problem...
>Claude,
>Sounds very interesting. I look forward to reading your article about your experience in the UT Magazine or on your web site <g> (hint, hint <g>)
>
>>Dmitry,
>>One way around this that I'm playing with right now is to put your app logic(the code that may change) in a VFP prg/fxp and just call that from the VFP COM mtdll(the key is to use CLEAR PROGRAM). The VFP COM mtdll is the part that doesn't change, therefore, you can recompile the prg with no problem and no interference ...
>>>PMFJI,
>>>
>>>I did a couple of small VFP/.NET projects where .NET was passing XML to Stored Procedure in VFP. It works but I would like to try the approach of using VFP COM. My concern with VFP COM was/is is that every time you make a change to the VFP COM you have to re-register it on the web server. Was it every a problem/concern in your work?
>>>
>>>
>>>>Hi Steve. I return XML strings from my VFP COM components, then C# puts this into an ADO.NET dataset and vice versa. Works much faster that I thought it would.
>>>>
>>>>>Are you using VFP COM objects? How do you move the data between .NET & VFP? ADO or XML?
>>>>>
>>>>>>
>>>>>>Use both .NET and Foxpro, that is what I do. Use .NET as your UI that calls your FoxPro data and biz rules and reports in your backend. This eases you into .NET.
>>>>>>
>>>>>>For Windows app development, I don't see reason to use .NET, but if you have a browser front end, then ASP.NET is the way to go.