>
>We do want to continue to enhance interop. But in some cases you are talking about merging, like with the .NET WinForm inside VFP behaving like VFP, and in some cases that won't occur. But this feedback is good, so keep it coming. If you have other specific ideas and needs around VFP with .NET interop, please let me know. What I need is very specific features and functionality backed by scenarios that explain why it is needed. I took note of your scenario above with the WinForm to research that, thanks.

Since it looks like interop w/.NET is mainly going to involve COM, being able to specify the class type of object properties and of objects returned by methods that actually get compiled into the type library would be great. COM interop for this kind of thing have gotten a lot better in later versions, but there is still room for enhancement. For example, if I call a VFP method through .NET, and that method needs to return an object reference, I have no easy way of .NET automatically knowing what that return object type is, because it's not available in the type library. Of course, you can do this using reflection, it's just not nearly as nice as it should be from the .NET side.

Using the _memberdata info to build the type library with correct casing would also be nice.

A way of preserving the case for properties of empty-style objects for COM interop and passing via web services would be slick. Eg. a nice way to tell VFP "here's going to be the interface for this object, don't screw with the case and make sure it's published in the TLB".

Put back the functionality you took out when VFP was going to be shipped with VS (some build of it at least) that let you easily debug into VFP COM components.

Again, there are ways around most of these issues. It's just not as easy as it should be, so anyone who wants to do interop ends up finding out these things the hard way.