>>I think I know the answer to this but before I invest a lot of time in research, I wanted to ask here. Someone has surely gone down this path already.
>>
>>My company wants to port a piece of an existing VFP app to .NET. The piece consists of one form with several subsidiary forms, all with lots of code behind them. The idea is to recreate the forms in .NET and reuse as much of the supporting VFP code as possible. Is this feasible? First of all, is it possible to compile VFP code into a DLL that is callable from .NET? And if so, how do you deal with the fact that the code is full of VFP field names and VFP PEMs like .Value, .Refresh, and so on?
>>
>
>Can you do it? Yes... Should you do it especially with the scenario that you describes which implies non-use of business objects - probably not...
>
>You can compile VFP code into DLLs no problem, but you have to be able to expose your logic in such a way that your client .NET code can get to it. If your business logic is mixed up with your UI code, that's not going to be possible unless you re-write the business logic.
>
>Many of the issues are addressed in this article:
>
>http://www.west-wind.com/presentations/VfpDotNetInterop/aspcominterop.asp
>
>It deals with ASP.NET but much of the content applies to any .NET application that needs to consume Fox code.


Rick,

Thank you. This is exactly the kind of input I was looking for.

To give you a little more info on what my company wants to do, this is one of those sales-driven project ideas. Corporate wants to carve out a key piece of our legacy VFP app -- really an xBASE app which uses VFP forms and reports but few VFP concepts -- and make it run as a web app. We slap a pretty front end on it and keep as much of the existing algorithmic logic, which is considerable, as possible. They want to have something they can demo (to demo, perchance to sell) at the annual client conference in April.

The business logic is completely intermingled with the UI code, as well as the data access layer. There are no objects of any kind. It's 1-tier, baby. As I said, the business logic is considerable -- it's basically a simulation tool with lots of complex financial calculations -- and it would be a project in itself to redesign it in proper n-tier style. Time I am not being allowed.

Here is the high level design my boss floated in my direction. A .NET web form, with subsidiary web forms based on user input, communicates with a VFP app. When the user clicks buttons or enters data, that request is passed through a web service to the VFP app, which consists of the pertinent parts of the existing app. The request and field values are passed as parameters. The VFP app is modified to accept the parameters and "refresh" the existing forms, which will now be hidden, and then invoke existing procedures which reside in .SPRs. The VFP app then passes values back to the web form and the web form is refreshed and ready for further user input. My boss thinks the VFP app has to stay alive, one instance per user session, to avoid state maintenance issues and the need to hit the database each time user input occurs. This function uses a dozen or more SQL Server tables, some of them quite large, and I don't want to have to repopulate them all every time. The user would turn into a skeleton, like in the old cartoon.

Does this sound do-able? I know it isn't elegant but I wasn't asked about that. I was only told this is what we're going to do, this is when it's going to be done, and how do we do it? And if it's not do-able in the time frame available, they want to know that. By Monday. (Halloween, appropriately enough -- trick or treat!)

I am totally green at writing VFP apps that interact with .NET services. I know you are far from green in this area and appreciate any input from you tremendously.

Mike