If you own the code you can just recompile the .NET code and make the component [ComVisible] and register for COM Interop (using regasm.exe) to register it.

If you don't have code you're out of luck however because the COM exportability will be determined by the developer's choices of the class definitions/interfaces.

There's another way you can do this as well using an intermediary layer that acts like a proxy for the component.

I've written about this here:
http://www.west-wind.com/WebLog/posts/104449.aspx

and have expanded on this a bit in our toolset as wwDotNetBridge which provides direct access to just about any .NET components including static code:

http://www.west-wind.com/webconnection/docs/index.htm?page=_24n1cfw3a.htm

For the straight approach using COM Interop check out:

Using .NET Components via COM from VFP
http://www.west-wind.com/presentations/VfpDotNetInterop/DotNetFromVFP.asp

Advanced .NET Article series:
http://www.west-wind.com/presentations/dotnetfromVfp/DotNetFromVfp_ComplexObjects.asp

Lots of options...

+++ Rick ---



>I seem to be doing the opposite of what most of the articles I've seen on the net regarding .NET/VFP interoperability are about. I've got a "legacy" VFP application that currently is 100% VFP, but I'm planning on making it a hybrid VFP/.NET application, with much of the front-end and driving logic in VFP, and data lookups in VB.NET.
>
>I've developed a .NET .dll that performs much of what I want to do, and tested it in a pure VB.NET environment - it works. Now what I want to do is test it in a VFP form. I've compiled the .dll with the "COM interop" switch on - is that enough to use CreateObject() to bring in the .dll?
>
>Any additional hints would be appreciated - thanks.
>
>David