>It appears that you think a utility that is a generic COM wrapper around .NET classes allowing VFP the ability to call "some" .NET classes directly is somehow better than simply taking a .NET class and exposing it as a COM object and calling it from VFP directly. It appears you feel that you may be missing out on something. Unless people actually need a utility, there is no benefit of putting in the significant resources into it since there are many other things that VFP developers are asking for which can help them in a practical way. I suggest you are more specific in what you are asking for and why. What exactly do you want and need, specifically, and why? Thanks.

Ken,

When you say "simply taking a .NET class and exposing it as a COM object", do you mean "simply installing Visual Studio.NET, learning how to use this new development environment, and developing your own COM object", or do you mean something else that can be done entirely through VFP? If the issue is that MS could supply a generic COM wrapper that would allow VFP programmers to put off installing and learning the .NET development environment while achieving some small measure of greater inter-operability with .NET, I would say that this definitely has some value, even if it's obviously not an optimal way to do things in the long run.

Please excuse my ignorance if I've got this wrong, but it sounds as though you're making an argument that might as well have been applied to VFP's ability to call the Windows API - oh, just go and write yourself a small Visual C++ or VB wrapper program to interface to the Windows API, and then call that from VFP. The point is to spare us the inconvenience of doing anything at all under a different development environment, until we determine for ourselves that it's worth the effort. You'd have a better chance of persuading VFP programmers to take a deeper look at .NET if you gave them the easiest possible way to take a peek.

Mike