Thank you for sharing. Sounds like a very interesting approach.

>I rarely have to reregister the DLL as long as the interface to the DLL has not changed (same public methods and parameters).
>
>My preferered method is to use a VFP COM object sort of as an Abstract Factory where I call a single method on the dll with enough information for the DLL to call a seperate prg (fxp). This way I can add functions without having to change the DLL. The DLL call gets 2 parameters (Function to Call, and the Parameter Itself which could be XML). ADO.NET does not do much with set based operations so I generally put a lot of logic in prgs to do most of the data manipulation in these functions even when working with other types of data sources like SQL or Oracle. I use this a lot when I have to outer join result sets between different data sources. I even have methods that I can pass VFP code as a string and use VFP's execscript() function.
>
>Troy
>
>>PMFJI,
>>I was wondering, have you compared the COM-based approach of updating VFP with calling a stored procedure in VFP? I am currently working on a small project where I use the latter approach (for the reasons you mentioned such as DML of VFP). My concern was when I was deciding on which way to go is that if you use COM approach and you hit a bug you would have to re-register the updated DLL on the web server. Has that ever been a problem for you?
>>
>>>I do this all the time to leverage the strong data manipulation tools of VFP. Simply add a COM reference to the DLL (I browse to it from the add reference dialog). .NET will automatically build a COM interop wrapper around the DLL for you. Then you can use it as you would any other class assembly. You may want to register the DLL by using the regsvr32 command.
>>>
>>>
>>>>If I create a VFP DLL how can I use it from C# code?
>>>>
>>>>Thanks