>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.aspIt deals with ASP.NET but much of the content applies to any .NET application that needs to consume Fox code.
