>May I know if there is an reliable way of calling a VFP COM from a .NET app?

A VFP COM server isn't any more or less reliable than any other COM server. Where you have to pay extra attention is that you don't change the COM interface accidentally. That is, do not introduce new public methods and don't regenerate the GUIDS. I specifically added a unit test for my COM projects to make sure that this doesn't happen (http://www.foxpert.com/knowlbits_200906.htm).

>Is there any reliable way to pass an object from .NET to COM and vice versa?

Yes. You simply pass an object and the COM server will receive it. The real issue here is not that things aren't reliable, but that many native data types simply won't work from VFP. For instance, you can't really pass a DataSet and use it from VFP. Hence, the interface should be a simple one, just passing around basic types like String, Int32, Double,... and objects with properties of basic types. Collections frequently cause problems with VFP, List< T > and other generics don't work at all. Regular arrays are fine, though.

>If not, what are the alternative to using VFP to run dynamic code in .NET

Many, depending on what you need...

1) You could create a class as a file and call CSC.EXE or VBC.EXE to build an assembly than load this assembly into memory. Very easy, but only works when you don't have to much code since assemblies cannot be unloaded.

2) You could use Reflection.Emit to produce IL code at runtime:

2a) Create a DynamicMethod object and add IL code.

2b) Use the CSharpCodeProvider or VBCodeProvider classes to compile code to IL.

3) Call a DLR language like IronPython using the IronPython.Hosting.PythonEngine object or Boo.

4) You could write your own parser and compiler. If your rules are simply, setting up your own domain specific language is a matter of a few days. There are many samples.